i’m still prototyping with the Flipsky mini FSESC 6.7 coupled with a Flipsky 6354 motor as discussed in my previous topic.
Right now i’ve successfully used the GenericSensor class in order to use a position sensor after a gearbox and i’ve modified the SimpleFOC library to separate the hall sensors (internally placed in the motor) that are used to the velocity loop to the generic sensor that i’m using only in the position control loop. So thank you @runger for the previous suggestions!
Now i’m coming back to the main issue of the controller, that is the “strange” sound of the motor and the spikes of the velocity control. By inspecting the graph of the speed and the motion of the motor, i figure it out that there was probably a problem in the hall sensor interrupt and that an incorrect speed was being reported to the speed control.
In fact, looking at the code, there are a few comments about the handling of false interrupts with some tricks. Then I remembered to have seen a similar problem in this forum and in particular this topic, I tried to substitute in particular the function HallSensor::getVelocity() posted by @Marc_O and in fact the difference is substantial as you can see from the following comparison:
With the modified HallSensor::getVelocity():
Just for reference, i’m using PlatformIO on VSCode and i’ve foud a very useful plugin to plot values coming from the serial that is teleplot that allow me to stay on the same enviroment.
So I wanted to ask you if the problem is known and if there is some workaround in the dev version.
You are absolutely right.
We have not touched the HallSensor code for some time now and now looking into the getVelocity implementation it is definitely not the best way of calculating the velocity.
We definitely need the minimal measurable velocity trick like the one suggested by @Marc_O. Current implementation will return 0 every time the time in between two pulses is larger than the time in between two pulses. If you are in to do a pull request with the changes please don’t hesistate to do it.
Otherwise I’ll try to refactor the HallSensor for the next release.
Thanks @Antun_Skuric for the fast feedback! just for “close the loop” now using that getVelocity() i can finally tune the PID of the controller! now by putting the LPF_velocity.Tf = 0.2f definetely improve the noise (before there’s was no difference) and then the tuning of the PID was straighforward. Also, before was impossible to touch the derivative term, i think due to the spikes. below a graph that start to be a good performance!
So at the end was the same also for the unbranded motor and the B-G431B-ESC1… but still the “strange” sound still hold in any working mode (current or voltage), i’ll do a small video to attach to the discussion.
Thank you for the advice on the pull request, I’m not an experienced programmer and so I’m not that keen on using github, but i’ll learn how to do and i’ll do my best.
Thanks for the reasonings! i’m going to understand well the differences between the two implementations. Just for feedback i’m really impressed for the simplicity and modularity of the library! especially now that i’m going more in deep. Moreover due to the fact that i’m mechatronic engineer (with a good electronic based) and i’m not so skilled on programming, but due to the object oriented structure of the library, i’ve modified the position and velocity sensor link method in few hours!
Probably i’ll give other trials to the B-G431B-ESC1 just for curiosity, so i can compare the inline current sense with the low side current sense…
Hi, Kindly can you tell me how you managed to use the generic sensor, I have a similar motor and with an integrated hall sensor, the data is not smooth, and also the motor is not running smoothly.
