RTS Interface progress + Problems with stopping and turning


I finally got my RVR fully interfaced with my existing body of work for a Real Time Strategy game inspired interface and wanted to share plus request some help.

First up, Here is RVR working properly in its turning precision. I am utilizing a speed of 50 here for rollStart commands, and rollStop to stop the unit. Please observe when the unit stops, it gradually decelerates instead of abruptly stopping.

On the other hand, Here is what happens after I bump the speed up to 100 and use rawMotors(0,0) to stop the unit from rolling since rollStop has an imprecise rollout. From what I can gather, the rawMotors command does not fulfill the rollout requirement of the rollStop command and it is queued up into the RVR if that makes sense. Once the unit is told to turn, it begins the queued rollout while turning which is what is observed in the video. To purge the rollout I have tried:

  • Sending a rollStop command AFTER the rawMotors(0,0) command so RVR verifies it is already stopped. This causes the RVR to lurch and actually FINISH the rollout prevented by rawMotors(0,0).
  • Sending a rollStart command AFTER the rawMotors(0,0) command with a speed of 0, same thing causes a lurch.
  • Sending rollStop or rollStart with a speed of zero before the rawMotors command stops the unit precisely, but still turns with rolllout.
  • Any variation of rollStart/rollStop + rawMotors(0,0) + delays still results in a lurch or rollout when the rollStop inevitably has to play out.

I’m using a Raspberry Pi running the Sphero Nodejs SDK. Any advice on how to get this thing to turn on a dime while using rawMotors(0,0) to stop without the rollStop rollout would be much appreciated.

1 Like

Tried using a driveWithHeading command instead of rollStart, the rollout still occurs.

1 Like

Hi @Eric_Reed,

That looks like a really cool project, it’s great to see the progress you’ve made so far!

As you may have noticed, rollStop is just a wrapper around _sendDriveWithHeadingCommand (see this file on gitHub) that sends a roll command to the robot with the specified heading and zero speed. That means that the yaw controller will still attempt to control the heading, causing a turn if the specified heading differs from the current heading. It will also apply a slew limit to the speed command, and take some time to ramp the linear speed down to 0. The rollout you’ve described is a bug in the slew limiting code. This mechanism, along with many other aspects of the control system, is changing dramatically in our next firmware update, tentatively planned for late Q1. This will improve the existing drive mode and supplement it with alternate drive modes that will probably be a much better fit for this particular project.

In the meantime, you could try implementing a ramp-down of the speed yourself while holding heading constant as the robot approaches the target position, since I assume you’re already either monitoring streaming locator data or polling the locator. If the robot comes to a stop while running a roll command, the retained slewing state information should be cleared out as far as I can tell, and you’ll be able to issue your next rollStart(0, newHeading) to turn it in place to face the next target position before starting to drive forward. That might be the only way of working around the bug for now. If you try it and still run into issues, report back and I can try some things to see if there’s another option.



Recommended fix was a successful workaround. Looking forward to the firmware update, I really want to get at that compass too. Especially looking forward to it if there’s more suitable driving modes :smiley: :smiley: :smiley:

1 Like