Can confirm. I hit the same issues you did, mine just throttled at soft rather than cut out at hard.
It was a software filtering issue on the analog input for temp sensors. The fix for it is in 5.2, but given @Venom121212’s reports I’ve not personally tested my SC 100S yet.
It sucks having to make tradeoffs and workarounds to make the best of a bunch of bad options for firmware.
In my experience in that thread the flakey temp reading definitely jumped in and out of throttling zone and you could feel it like a stuttering. when it jumped far enough to throw a fault you get the full fault cutout. you could see it in metr.
Did we ever had a data smoothing for the temp values in earlier fw versions?
The ones I used for a long time (3.61,3.62) didn’t seem to have had it. As minimum you could see the temp jumping ±10degree depending on how close the temp wire was routed to your phase wires and depending on the acceleration for sure.
Ok, I think I see that in the code.
on apr 9th. there’s specific commit to fix a motor temperature sensor bug. Introduced on mar 15th. Both of these commits are in firmware 5.0. I’m not sure who would have picked up the bug because it’s not clear to me when releasees were made. but it’s both introduced and fixed in the changelog for 5.0
As I read the bug, and I could easily be wrong, it would have meant for those configured to use NTC 10k thermistor, temperature filtering would be bypassed.
In more detail: the current sample would have been used immediately as temperature, and the temperature 0 would have been merged in using the low pass filter. instead of merging the current sample in with the previous temperature using the low pass filter.
fixed:
I think Yes. as early as 3.17
However, it’s true that several of us have seen more noise than desired anyhow.
and I note that @Deodand slowed the LP filter down for stormcore and unity and Benjamin seems to have applied that change to all hardware a few days later. all that is in fw5.0
So… I think that fw5.0 might actually be a fix for wild temperature sensor values that existed from the beginning of vesc. hw and cabling dependent obviously. or it’d be a bigger deal than it was.
Except… there’s the median filter bug, introduced the in the same fw5.0 commit that added the slower LPF,
and then fixed later in fw5.2 (on dev branch)
So based on my code spelunking just now, I think this is “not enough low pass filtering for motor temp” and it’s existed since low pass filtering was introduced and of course prior. unless there’s something specific introduced in 4.0 I didn’t find it.
So I updated the list to note it’s all firmware versions up to 5.0.
Also updated the median filter bug to be 5.0 - 5.1
I think the temperature issue might be more complicated than this.
All VESC 6 hardware I’ve seen has a 1uF filtering cap on the sense node, at 10k, this forms a hardware lowpass filter with a cutoff frequency 16Hz. This should remove basically all noise in the measurement.
Something tells me there’s crosstalk in between ADC channels.
I also looked at the median filter
Why the hell are you running QUICKSORT on an array with NINE elements, in a hard real-time system?
If you’re so determined to use sorting to find the median, use insertion sort! It’s iterative and it WILL run faster! This is comp sci 101. Nothing beats insertion sort on fewer than 40 elements!
Alright, I might actually submit a pull-request fixing this egregious breach of basic computer science principles.
It might not actually have any impact in the end, but like WTF?
But forget the median filter, it’s unnecessary, all you need to do is implement a proper four pole butterworth filter using this calculator.
https://www-users.cs.york.ac.uk/~fisher/mkfilter/trad.html
A median filter actually PRESERVES certain high frequency noise!
Might’ve been the first sort he decided to use and didn’t go back to optimize it (it happens). I would always go quick sort first and then go back to see if another sort will be better. Let’s not act as if none of us have ever at least once overlooked a basic CS principle before in our careers.
This is embedded systems, not a CS assignment. This oversight SHOULD NEVER HAPPEN during development. Basically what I am saying, is no embedded systems developer would choose quicksort as their first pick goto sorting algorithm, even for prototyping unless it’s arduino or some IoT stuff that isn’t subject to hard real-time deadlines and going into a professional product.
I would expect a professional product to be subject to code reviews.
Hence the word careers
I would agree with you. Moreso if this were a company with code reviews. I’m willing to bet that there are a sum of choices in the code that would not get past a company review.
I would , it’s quicksort, as basic as it comes. If I’m trying to see if an idea i have works I’m going to worry about making sure it works first then come back and do a proper sort implementation later. It seems Vedder might not have gone back for that step.
This isn’t a product that neither you nor I have have paid professional $’s for. It’s an open source project we’re allowed to fork and have anymore we want. Do I agree that it should have been code review ? Of course. Would I ever act so arrogant to another programmers code , Especially one where they dedicated a good chunk of their time to release to the community for free ? Never.
I see a mistake, even a trivial one ? I fix it up or point it out and keep it moving. Arrogant Comments don’t power out board s
Except Trampa made it into a professional product, the moment that happened, the entire repository should have been subject to a code review.
Here’s what goes through an embedded systems developer’s mind “I need to sort some numbers, insertionsort is pretty simple, let me whack that in”. quicksort never once crosses the developer’s mind because they’re trained not to call recursive functions unless absolutely necessary.
There are lots of these things happening that would take way too long to describe in detail.
Open sourcing is to provide a stable platform for others, not crowdsource bug fixes.
Anyways, I submitted a pull request for it, let’s see if it happens.
Come on bro. Everyone here has an idea of the agreement between Trampa and Ben , and it didn’t detail another programmer to assist Ben. Trampa , no tranpa , it still Ben writing your the entire the entire code base. I’m not saying a code review isn’t/wasn’t due. I’m saying when mistakes are made the least it can be met with arrogance.
I see. I still don’t think it should be met with arrogance. But that’s just me
Agreed. But I still find it in bad taste. It’s like a co-worker snorting at a small mistake you made when it should be a cooperative endeavor.
You are right, what I am saying is pretty arrogant but here’s the thing, is it really a cooperative effort?
Trampa is making money off the VESC, quite a large margin for that matter, while Chinese companies are spinning off clones and screwing over customers.
Why should you or I invest our own valuable time to fix someone else’s problems that they then proceed to profit off of?
I paid good money for a trampa VESC 6, why should I have to fix problems myself in the firmware?
That’s true, I’m about to dive into this to see if I can implement a Push Assist Mode but I understand. It’s a weird situation, one that’s not helped by Trampa’s behavior. Let’s hope the future is ESK8 brings something that rocks the boat. But I think we’ve derailed this thread a bit unfortunately.
If you paid someone quite a sum of money to build you a PC
and they then proceeded to build it the way The Verge built it (I’m using an EXTREME example here)
you would, at the very least have some things to say, wouldn’t you?
No but it’s a principle of mine: if I ask for something and it’s not done in the way I want , I yield my right to to be angry since i should’ve done it myself. Especially so when it’s something I can’t do Myself. But that’s just a weird thing of me. Mind you I’ll get my money back of course , but I just can”t get angry.
Rest assured, I am doing more than getting angry, I have my own solution coming soon.
Yeah, I totally agree.
which is why I was digging in trying to get a little more clarity on motor temperature related claims.
I’m also doing a difficult thing trying to simplify a complicated issue into a short line item on a list.
I almost chose to leave it out. but it has been claimed more than a few times. And the fw5.0 change to slow the software LPF is a mitigation of that sort of problem so I though worth capturing that somehow in the list.
I think maybe what you’re getting at is it shouldn’t happen hw wise, and that’s weird. so maybe it’s something else. or maybe it’s beyond the filtering cap. and solving in software is more a workaround than a fix. ?? at least that’s how I’m feeling it. makes sense.
and vedder made the same point that there’s a hardware filter as well as software filter
Are you sure that temperature measurement noise is causing that? There is both a hardware and a software filter, and I haven’t experienced any noise on the temperature. Do you know what the sample rate of that log is? I haven’t used the metr app.
thanks! I appreciate that. and I’m only an onlooker.
EDIT:
I added “not exactly a bug” to the list.
Are you even aware of how abrasive and obnoxious/arrogant you come off as? Having met and known Ben and also having read your thesis and seen your code it’s pretty clear to me who is someone revolutionizing open-source code for motor control and who is busy strutting around like a know-it-all trying to show off how much CS classes they took. In general I try to be a positive guy but nobody should get a free pass to act like as much of a prick as you have been toward a guy that out-classes you so far in character and intelligence. You look pathetic trying to pretend you are at the same level as him because you wrote some derivative BLDC algorithm that you pretend is some revolution when its actually just regurgitated ideas from the 1900s.
Sorting 9 items in a list at 1 kHz in a low priority thread is pretty damn cheap relative to the rest of the code. It’s always nice to optimize but it also takes time and won’t make any observable difference to the performance of the controller, in that way it is a pretty stupid way to waste time so should be a perfect task for you. I can see you seem to enjoy wasting time trying to slam a guy that has never wronged you in any way.
The motor temp problem stems mostly from the fact that not everyone is running the same analog LPF on the motor temp sense and the lack of control on routing of the sense wires in the motor. I think a lot of the hardware has higher cutoff frequency around 100 hz which means noise passes through up to 1kHz. The vesc 6 LPF definitely makes this issue less prevalent. If you want to know why noise is coupled into the motors temp sense all you have to do is look inside a motor to find all the terrible coupling you need:
We’ll continue trying to improve the code to get reliable performance but there is only so far digital filtering can go when aliased samples are taken. On the stormcore we ended up swapping the cutoff freq of the LPF to address this but there isn’t much I can do for all the people using unity’s out there, except to say get a motor with better temp-sense routing.
