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.
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.
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.
@Gamer43 you come across as a spoiled petulant child that knows how to spell more big words than he actually comprehends.
I’ve seen you repeatedly disparage this project, yet none of your own work that has been published leads me to believe you have the skillset to criticize it in such a manner. And when I’ve asked you to actually back up your claims you’ve utterly caved and admitted you don’t know enough to back it up. So which is it?
Why don’t you choose to contribute and learn rather than endlessly bray about your “much better than VESC” vaporware ESC?
Chill out. The aggro attitude isn’t earned or deserved here.
I try to be a chill guy, but this really gets under my skin. Nothing bothers me more than people with just enough context on an engineering problem to give a 50% informed opinion and pass it off as an expert opinion. There’s not a ton of people on this forum with the education to decry what he says as BS so we waste experts time managing this garbage.
Combine that with the steady stream of undeserved insults levied at vedder and I get fed up pretty quick. I consider myself to be a well-educated and nice guy, and on meeting Ben it became evident he’s got me beat in both categories. The dude is like an encyclopedia on this kind of stuff, seeing someone put a magnifying glass on any mistake he might make to try and make jabs is just childish and deeply disappointing.
Hard to say without opening the motor and looking how the sense wires are routed. Having the gnd and temp sense wire run next to each other is what you want.
Wouldn’t be the issue solved in just taking the middle value of the last 5-10sec input temp values? I mean the temp value is not a super time critical value. It’s not like the motor temp will rise 20 degrees in 1 second and even if the motor temp would rise that fast the 80/100 degree cut off limit is still so low that every quality motor should be able to handle a 10 second overheating of maybe 110 degrees.
That’s already what is done. Do some reading on aliasing and niquist frequency if you want to better understand the sampling issue, but it breaks down to a continuous time sample being taken discreetly. So with a coupled noise it’s possible to always sample at the incorrect interval to gather biased data even when averaging the discreet samples.
Twisting the motor sense wires wouldn’t hurt anything but probably shouldn’t be needed. I think it’s just when you have this kind of worst case routing where the wires are encircling the coil of the motor. This is literally how transformers are made.
I’ve heard others use the No Limits version of the software and set the cut-offs to some ridiculously high number, but I myself have not tried that option
Don’t know if this has been mentioned here or in other threads or not, but I think safety is good enough of a reason to warrant repeating information:
@kevingraehl discovered a bug on his Unity that I later reproduced on a Trampa Vesc 6 running FW 5.1 where connecting a UART device such as a Metr module causes a remote cutout. That’s the observed behavior, what it probably is is a short reboot or something. @ducktaperules says it’s because of “safe start” turned on. So if you have a Unity, use some glue or something to make sure your bluetooth module doesn’t disconnect & reconnect mid ride!
Many people (including myself) have discovered that having the “Maximum duty cycle” and “Duty cycle current limit start” values equal will cause the motors to abruptly stop once they reach this value.
Found on FW 5.1, according to @DerelictRobot this also affects FW 5.2. If you use the “duty cycle current limit start” feature, make sure to test it on the bench before you ride! Having it at 100% disables it I guess, but then you have to be prepared for a sudden loss of acceleration when you reach top speed, just like you would before.
Sorry for tagging you and putting words in your mouths guys, I hope my language was vague enough that you can step in and clarify anything I got wrong.
Good write up! I hit the max duty cycle error you mentioned. It was not fun. Good to see some diagnosis on it.
When I set it to 100% it caused my motors to get really wobbly like they were oscillating back and forth at full throttle, like they were out of sync or something. Interested in seeing if anyone else has the effect.
Sorry to revive this dead ass thread but I have this oscillating at 85-95% duty cycle on Acks3.103 (Sensored, FOC) and Vedder 3.62/65 (Sensored, FOC) and have heard that it is due to the default sampling rate of 30khz and potential solution is raising it to 35khz where you’re now susceptible to the watchdog error/fault from the MCU running out of resources. If you ever found a solution Justin let me know.
