I just want to clarify how the monitor works and how the
motor.monitor_downsample value affects it.
Would I be right in thinking the value in
motor.monitor_downsample is the number of times the
motor.loopFOC loop runs for one set of values printed on serial. So if this value is set to 100 the loop will run 99 times and on the 100 time, it prints the values requested on the monitor?
How can get these variables to use in other calculations?
There is also
motor.motion_downsample which does the same thing for the move() function.
Not sure what you mean here? Do you mean the missing values for iterations 1 to 99?
Those are simply “suppressed”, you don’t get them. The problem is that any normal MCU and Arduino code can’t output fast enough at motion_downsample=1 without it strongly affecting the main loop iteration speed. You have to set the motion_downsample to a value where your main loop remains fast enough, depending on motor and speed you want to reach, this should be >1kHz, maybe even better 10kHz.
If you wanted to do monitoring at that speed you would have to use something like a STM32F7 or Arduino Portenta, MCUs which can do fast USB. And it would presumably involve a lot of custom coding, since I doubt the Arduino serial class would be sufficient.
What does this actual output?
sorry no, it is not what I meant (sorry for being vague).
How do I get say motor angle, if I want to put the value into an equation if a gearbox is added to the motor and I want to calculate the position of the output shaft?
It just reduces the frequency with which the move() function does its thing. It does not actually print anything.
You can use
motor.shaft_angle or you can call the methods of the sensor:
On a side note
I am currently running an ESP 32 and have to turn the motor.monitor_downsample up to 250 this gives me around 120 samples per second. I find if I lower the downsample I can get up to 500 SPS but I find it is almost possible to send any commands over the serial.
why would this be?
One would have to investigate this in detail, but my assumption would be that the reason is that the monitoring and the commanding is competing for bandwidth on the same serial port. When you lower the downsample, the serial buffer is always 100% full and the commander always has to wait when sending its responses.