A Problem Using API's

My comments are based on an analysis of the python examples for the micro::bits coprocessor.

One would expect that when a drive api, which sets direction and speed, is sent to the RVR, that the RVR responds until a new command (api) is sent. However, this is not the case. The RVR stops after a short time. In order to maintain the desired motion, a loop must be defined to resend the command every 200 ms. Besides the unnecessary redundancy (the api is constantly redefined), I feel that this is a weak link in effectively controlling the RVR drive. Can this problem be corrected?

Also are the RVR motors encoded?

Nick Lordi

1 Like

I’m using the Nodejs SDK on a raspberry pi and have the same problem. I ended up making a movement loop that checks against distance moved and sends a raw motors command every 100ms. Would love a fix. I’ve read that there’s a Q1 firmware update otw, hopefully it will be addressed there.

1 Like

This is standard practice for robotics. You don’t want the robot running off. My experience is the time out is more like 2,000 ms. My code is undergoing refactoring so can’t test it at the moment.

Again, per other messages, the motors are encoded but that is not available with the Api. The locator is the best you can do. A statement was made that encoders might be in the next major firmware release.

A general observation about robotics is you need to sample and update commands quickly. A 50 msec loop is probably a good target for the RVR. The fastest the streaming sensors report is 30 msec, which is another possible loop interval.

Consider that at full speed, say 1.5 m/s, the RVR is going to travel .075 m (3") in 50 msec.

1 Like

I’ll see if I can get my sensor streaming to work at 50. I had a problem with my interface not sending commands at higher sample rates for some reason. Thanks for all the info!

1 Like

I just tested the drive timeout and found it to be 2,000 msec. It was a 10 iteration loop that sent a raw drive command then waited for 3,000 msec. It would stop after 2,000 msec and then start again.

You might look into the Python code to see if it is setting a timeout of 200 msec. When I looked at the code I saw there was the ability to set a timeout so maybe they are doing a default of 200 msec.

1 Like