Hi,
Just received the ODrive V3.3 and set it up with AS5074 encoders. The whole setup works quite well- I actually expected more fiddling with setup.
The question I have is- has anyone done any measurements on the processor utilization? I.e. are there spare CPU cycles to execute simple control algorithms which then control the motors?
Also, how frequently is the current control loop executed?
Thanks for sharing the fact that things went smoothly: usually people post when they have problems, its nice to hear about the times when things go well too!
Right now there is no CPU utilization counter, but you can make one. In freertos.c, there is an idle thread called defaultTask (it has thread priority of osPriorityIdle). At the start of the program it calls StartDefaultTask, then quits at the bottom:
//If we get to here, then the default task is done.
vTaskDelete(defaultTaskHandle);
Right before that part, you can instead make it call a new function, that you make, that has a loop that simply increments some 64bit number. Ideally we would make this loop with inline assembly, to insure known loop period, but a C loop and measuring the time, and keeping compiler settings the same, should be okay place to start.
Then, in the motor control threads, we can check how many counter loops elapsed between control cycles (the period of which is CURRENT_MEAS_PERIOD, defined in main.h), and hence get a measure of spare instruction cycles, which could be presented as a percentage.
CURRENT_MEAS_PERIOD is also the answer to your second question 
I have also had good experience using FreeRTOS runtime stats functionality if there’s a spare timer: http://www.freertos.org/rtos-run-time-stats.html
I’ll probably do the measurements if the project I’m working on is headed towards cramming the functionality in ODrive firmware, so I’ll let you know.
If I followed the defines correctly, CURRENT_MEAS_HZ is currently 8241.8Hz.
Ah cool, yes that’s a neater solution, thanks!
Yes you are very welcome to install that, there are indeed spare timers.
Cheers!
Is this also the PWM frequency for the motors as well? If so I’m curious of any reasons not to run the PWM higher? I know it has to be in sync with the current sampling and there may be some switching limits between the FETs and the gate drivers. Just wondering for audible reasons.
Thanks!
Yes it is the PWM frequency (and the ripple frequency aka “inductor frequency” is twice this).
Indeed you can hear the 8kHz and the 16kHz. The 16kHz should actually be higher magnitude, but our ears and mechanical filtering means that 8kHz is more audible in my experience.
Right now I naively run the entire control loop every current sample, and the limit is the available CPU time. The plan is to turn on compiler optimisations by default, and to use the hardware feature that triggers the timer event only every n PWM cycles. Certainly the plan is to have the PWM frequency above audible.