Proper way to detect if motor is stuck during its move?

[mrdc]

Hi,

Thanks for your project!

I'm new to Boost and have a question concerning detection of motor stall during execution, which prevents further program flow. For example, I'm assembled a MOC and an app, which was included with it has some movements, but when I run it as is, motors stall (they are physically limited) and the whole app freezes. I understand the synchronous nature of pylgbst, so maybe there is some sort of a callback etc, which gives me the control when a motor is stuck not reaching the final position?

[undera]

You can always subscribe to motor's rotation sensor, so it will tell you what happens with the motor and you will be able to track situation when you sent the command to rotate, it did not finish yet, but the motor is stuck. It takes a bit of programming to do so.

From my practice, it is the best to avoid calling commands that rely on exact angle of rotation, if there is a chance for motor to get stuck. Think of it - it is quite logical that if you expect it to reach certain angle mechanically, it is not good to continue if it has not reached it. It may lead to mechanical damages of your robot.

As an alternative, you can use timed commands, if appropriate.

[mrdc]

You can always subscribe to motor's rotation sensor, so it will tell you what happens with the motor and you will be able to track situation when you sent the command to rotate, it did not finish yet, but the motor is stuck. It takes a bit of programming to do so.

Looks promising: I can compare current pos and final pos to check and act.
Thinking of it as some sort of self-calibration at start: an app tries to find max angles and adjusts its work according to it.
At the moment, I've made some manual adjustments to original code to fix the stall, but I want to find a better way - full auto, for example :)

Let's keep this issue open - I'll do some tests and post results.

[undera]

You can see the initialization sequence in some of my videos. When robot starts, it invokes rotation of "timed" type so it reaches some known limit. Then from that limit it rotates to the angle of "initial position". For example, in Vernie video, it always makes sure the head is straight.