Sphero RVR - Blocks 1 square - robot travels too far

Hi There.

I have recently received a new Sphero RVR to do some programming with my son. In my attempt to carry out the first lesson an get the RVR to drive in a sqaure, I have spotted a weird phenominon, where the robot drives longer on the first side of the square to the remaining three. I have attached a screenshot of the associate sensor data.

Please could someone advise why this is happening? Is the product faulty or am I missing something here?


1 Like

Just by way of an update I think I have figured out that the issue is latency when streaming code from the laptop to the RVR. Below is a screenshot of a 2nd run of the program where I increased the length on each side of the sqaure by adding time. The result is the same 20 - 30 cm dead patch at the start which I can only imagine is where the motors have been given the command to run, but the program has not yet started.

Perhaps someone else could confirm this for me?

1 Like

Hi @MondyCode2021,

Let me shed some light on this behavior. Your RVR appears to be perfectly normal, though this corner case can certainly be confusing. The firmware follows this rule:

If stopped when a new drive command is received, turn to within (IIRC) 5 degrees of the target heading before driving forward. Without this, the corners on your locator plots would be noticeably curved.

On the first move, RVR is already facing the target heading and the entire driving time is spent traveling forward. On subsequent moves, there is a 90 degree turn occupying some of the specified driving time. You can verify this by offsetting all the headings 90 degrees to force an initial turn.

If you believe that you followed one of our example activities exactly, then we should modify the example to fix this. Can you send me a link to the specific example you were following? Being on the firmware team, I’m not very familiar with much of the supporting content for RVR.

As an aside, latency from the BLE connection should generally be quite low, on the order of tens of milliseconds. This is occasionally higher on some devices due to issues with particular manufacturers’ Bluetooth implementations, but I wouldn’t worry about it in your case, based on the observations you’ve shared so far.

I should also mention that RVR has much higher precision in other drive modes that are not yet supported by EDU. The Raspberry PI Python SDK can send drive to position commands, which I’ve measured at 5mm of final position error driving a half-meter square on a hardwood floor. This is planned to eventually come to micro:bit as well when we have the bandwidth to revisit that platform.


1 Like
SPHERO Email Marketing -