Known bad firmware versions VESC/UNITY [ SERIOUS ]

Yeah not temp related.

My issue was the motors oscillating back and forth at full remote throttle. I could be going full speed at 75% throttle but would start feeling insane speed wobbles start up if I pushed the remote throttle 1mm further.

The suggestion was to turn down the Max duty cycle limit start to 85% but that made my board feel like a mule reaching top speed.

No faults recorded after my crash.

Not sure? Not sure it matters? What I read is that the data-smoothing was removed from the temp value, which caused all the noisy data. If that noise jumps for even a second above the hard temp cutoff, then you’re eating street. I dont remember where I read that, I have had a bunch of conversations about this across several threads. Im pretty sure I read that in the FW4.x thread. Not certain though.

1 Like

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.

1 Like

It sucks having to make tradeoffs and workarounds to make the best of a bunch of bad options for firmware.

2 Likes

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.

2 Likes

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.

1 Like

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:


introduced:
1 Like

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)

1 Like

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

1 Like

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!

6 Likes

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.

2 Likes

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.

3 Likes

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

5 Likes

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.

7 Likes

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.

2 Likes

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?

6 Likes

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.

@BillGordon :sweat_smile:

4 Likes

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?

3 Likes

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.

1 Like

Rest assured, I am doing more than getting angry, I have my own solution coming soon.

4 Likes