RVR stall notifications not working

Hi all. I’m working in Python on RPI with RVR. Movement is working fine, but I’ve run into a problem I haven’t been able to solve. I enable stall notifications and set a handler (literally copied from the example in the SDK), but when I tell the RVR to move forward while holding it back with my foot, I get no stall notification. Has anyone else encountered this problem? Any clues? Thanks.

1 Like

Update: I just tried the verbatim example (getting_started/asyncio/motors/motor_stall_notification.py) and it also does not work. Stall notifications are never received no matter how long I hold the robot in place. Is anyone receiving these? Do I perhaps have a defective RVR?

1 Like

Hmmm… Maybe I’m posting in the wrong forum?

Below is the verbose log output. All those move forward commands are happening with my foot on the RVR. This shows that the command handler for the stall notification is created but it seems that the RVR SDK is never receiving a stall notification from the RVR. Is anyone else able to receive a stall notification using this SDK?

Message created: COMMAND 1: DID: 0x13 CID: 0x0d Payload: ERR: None
No response requested, sending message to port
Writing serial data: [0x8d, 0x18, 0x01, 0x13, 0x0d, 0x01, 0xc5, 0xd8]
Message created: COMMAND 2: DID: 0x16 CID: 0x25 Payload: ERR: None
No response requested, sending message to port
Writing serial data: [0x8d, 0x18, 0x02, 0x16, 0x25, 0x02, 0x01, 0xa7, 0xd8]
Command worker added for DID:22 CID:38 Target:2
Message created: COMMAND 3: DID: 0x16 CID: 0x01 Payload: ERR: None
No response requested, sending message to port
Writing serial data: [0x8d, 0x18, 0x02, 0x16, 0x01, 0x03, 0x01, 0x80, 0x01, 0x80, 0xc9, 0xd8]
Message created: COMMAND 4: DID: 0x16 CID: 0x01 Payload: ERR: None
No response requested, sending message to port
Writing serial data: [0x8d, 0x18, 0x02, 0x16, 0x01, 0x04, 0x01, 0x80, 0x01, 0x80, 0xc8, 0xd8]
Message created: COMMAND 5: DID: 0x16 CID: 0x01 Payload: ERR: None
No response requested, sending message to port
Writing serial data: [0x8d, 0x18, 0x02, 0x16, 0x01, 0x05, 0x01, 0x80, 0x01, 0x80, 0xc7, 0xd8]
Message created: COMMAND 6: DID: 0x16 CID: 0x01 Payload: ERR: None
No response requested, sending message to port
Writing serial data: [0x8d, 0x18, 0x02, 0x16, 0x01, 0x06, 0x01, 0x80, 0x01, 0x80, 0xc6, 0xd8]
Message created: COMMAND 7: DID: 0x16 CID: 0x01 Payload: ERR: None
No response requested, sending message to port
Writing serial data: [0x8d, 0x18, 0x02, 0x16, 0x01, 0x07, 0x01, 0x80, 0x01, 0x80, 0xc5, 0xd8]
^C
Program terminated with keyboard interrupt.

1 Like

Hi @gorsat,

Sorry to keep you waiting. I generally check the forums a couple times a week so I just spotted this thread. I wrote this feature in the firmware and would be happy to help you debug.

Are the treads moving at all when you hold it with your foot? The criteria are pretty narrow for our stall notifications, since the onboard stall protection response of disabling the motors for a few seconds is designed to protect against sustained motor stalls that would dump a large amount of heat into the motor windings, without interfering with non-harmful driving. It requires less than 18 mm of linear tread motion over a 5 second period, with high continuous motor current. That means that it won’t trigger at low duty cycles, and won’t trigger if the robot is prevented from moving but the treads are slipping.

Being a firmware/electrical engineer, I don’t have a ton of experience with the SDK. How did you turn on verbose logging?

-Jim

1 Like

Hi Jim,

Thanks for the reply.

Yeah, when I run the stall example I can hold the rover completely still for several seconds while it’s trying to move forward and a stall notification never comes.

But I probably have the wrong expectation of what “stall” really means here. It sounds like it’s more severe than just “the motor wasn’t able to rotate for a couple of seconds”. It would be good to know what the right expectations are for this notification, though.

At any rate, I’m able to use the speed sensor stream to get the data I need, so I’m not blocked.

To turn on verbose logging in the python SDK:

from sphero_sdk.common.log_level import LogLevel

rvr = SpheroRvrAsync(
    dal=SerialAsyncDal(loop),
    log_level=LogLevel.Debug_Verbose
)

Interesting. Was this with a freshly charged battery? The left_speed=128 and right_speed=128 inputs to rvr.raw_motors() in that example are a bit lower than I’d have selected to guarantee triggering the event. That will apply 50% duty cycle PWM to both motors, which should just barely put the motor current over the threshold if the battery is low. Add in component tolerances and measurement noise, and it could definitely be the reason for not triggering stall protection. Bump up the duty cycle values to 255 and see if it triggers.

When the stall protection mechanism triggers in the firmware, it disables the motor drivers for a few seconds. The goal of that is two-fold:

  1. To limit the on-time of the motors when the robot is apparently stuck and stretch out the temperature rise curve.
  2. To encourage users to take action to avoid the situation going forward.

The purpose of the notification is to enable users to develop error handling around it, and allow the EDU app to provide UI messaging. We didn’t want to disable motors without the ability to programmatically detect the cause. It’s not suitable as prompt feedback for having run into an obstacle, and we could definitely flesh out the description in the docs to make that clear. There will be much more detailed control system documentation coming out with the next firmware update, so we’re aiming to be less mysterious going forward.

Thanks for the tip on the log level!

-Jim

1 Like