Info on on_motor_stall_notify for RVR?

Could someone explain the response sent to on_motor_stall_notify handler?
I assume index is motor number?
What about isTriggered?
What’s difference between triggered vs not triggered?

Hi @jl303, welcome to our forums!

I initially thought I’d point you to our documentation on the SDK site, but that definitely needs to be fleshed out more. More complete documentation is on the TODO list after we ship new RVR firmware. In the meantime…

Left motor index is 0, right motor is 1. This async is edge-triggered on a change in the stall protection state for either motor, so that stalls may be programmatically detected and handled in user applications. When isTriggered==True, the protection is active and neither motor will be powered. Stall protection self-clears after 2 seconds, generating a new async where isTriggered==False to notify clients that driving is available again.

Happy programming!

Jim, thanks so much for answering all my questions!!!

On a related note, it seems like threshold for stall notification is pretty high.

If I face RVR front of a wall and issue a forward command once, the treads are trying to turn but unable to do so as expected. Then I can hear quiet but squeaky sounds indicating that motors are having a problem. However, it does not generate stall notification.

If I issue move forward command like 5 or 6 times rapidly in succession (maybe within 1 or 2 seconds), then it does generate stall notifications.

Is this normal, or are the motors on my RVR defective?

I’m definitely having a blast! Perfect stay home project for pandemic

That’s all normal behavior. The squeaky sounds are from the current limit being enforced by the motor driver. Heat is the enemy of motors and the current limit is the first line of defense to slow down temperature rise. The second line of defense is the stall protection mechanism, which is designed to provide protection against sustained high-current stalls while minimizing interference with normal driving. That’s why the bar is pretty high for triggering it - there has to be very little movement and continuous high current for 5 seconds in order for it to trigger. With the drive commands timing out in a little over 2 seconds (bug fixed to be consistently 2 seconds in our upcoming firmware release), I would guess your commands that eventually triggered it were sent over about a 3 second window to reach that 5 second threshold.

I’m glad you’re having fun with it!

P.S. The 3rd and final line of defense is thermal protection, which estimates motor temperatures over time and forces a cool down period if they get too hot.

Jim, thanks again for your detail explanation!
I was trying to use stall notification as a way of detecting obstacle.
Your description sounds much more serious, and the threshold is set high on purpose as motor protection.
Is it ok to assume that it’s not a good idea to utilize stall notification in that way to avoid damaging the motors?
Would it be possible for RVR to send notification with different levels as obstacle detection purpose?
If not does RVR have a way of detecting obstacle other than outfitting with third party proximity sensors?

Thanks again for your response!