RVR Firmware Update Preview

#1

Hello RVR users!

We’ve been talking about improvements to RVR’s control system for quite a while, and we appreciate your patience while the team here has been hard at work bringing those to life. Schedule details may still shift, but at the moment it looks like we’ll be able to release new RVR firmware in early summer. Due to resource limitations, our public SDK’s may not support any new commands until late summer or early fall, but the features will be present in firmware and documented for those who don’t mind low-level programming. Here’s an update on the firmware changes you can expect:

Control System

Previously, one driving control system was available to users through roll commands, requiring a target heading and a target speed, with an optional reverse flag.

This update replaces the “roll drive” controller with a higher-performing, more configurable implementation and supplements it with 3 selectable alternate control systems. All control systems present a normalized interface, similar to current roll commands, and an SI units interface where linear velocities are specified in m/s and yaw angular velocity (if applicable) is specified in degrees/s.

The list below does not include everything targeted for the release, but represents the features that are complete at this time.

Improvements: Roll Drive

  • Vector drive state machine
    • State 1: If currently stopped, spin in place to face the target heading
    • State 2: Drive along the target heading
  • User-adjustable yaw and linear velocity slew rates.
  • Default yaw slew behavior is dependent on the magnitude of the commanded linear velocity (to make deliberate, slow driving easier). See video for comparison to released firmware
  • Yaw targets are typically hit within +/-1 degree of the IMU reading. Previous tolerance was +/- 3 degrees. See video for comparison to released firmware
  • Steady-state yaw error during driving tracks to zero across the full linear velocity range (a bug had previously reduced yaw control accuracy at high linear velocities)

New: Drive to X-Y Position

  • Provide a target position and orientation as (X,Y,heading), along with a maximum linear velocity, and RVR will rotate to face the target position, drive to the target position, and then turn to the specified orientation, sending an API async when done. See video for demonstration.
  • Defaults to driving forward to the target position, but supports options for reverse driving, or automatic selection of forward or reverse to minimize the required initial turn.
  • Supports relative or absolute coordinates

New: RC Drive

  • Provide a linear velocity, and a yaw angular velocity, and RVR will follow that command until it times out (default 2 seconds) or a new command is received.
  • Supports multiple adjustable options for linear acceleration rates, so your project can keep delicate payloads safe, or put the pedal to the metal.

New: Tank Drive

  • Provide left and right tread linear velocity targets in normalized or SI units form, and RVR will track these targets. If your goal is to build an externally hosted control system, this is a much more useful interface layer to use than raw motor commands, as the onboard velocity controllers update at 1kHz and the maximum streaming data update rate to provide feedback to an external control system is 100 Hz.

Encoders

  • Encoder position resolution has increased 4x due to counting all quadrature edges as ticks rather than full quadrature cycles.
  • Velocity measurement has improved with changes to the encoder driver.
  • Tick counts for the left and right encoders are available as 32 bit signed integer values.

Locator

  • RVR’s locator precision is improved. There was a bug that caused loss of precision at low tread velocities, which has been fixed. Precision is now independent of tread velocity.

Other Bug Fixes

  • Idle to “soft sleep” (standby) transition now occurs after 5 minutes, as designed, to reduce power consumption.
  • Resolved “lurching” bug in the roll drive controller.

If you have any questions, feedback, or concerns, please let us know in this thread. We are very excited to share these details, and look forward to the actual release to you, our RVR users.

-JimK
Senior Firmware Engineer, Sphero

2 Likes
RTS Interface progress + Problems with stopping and turning
2020 Q1 RVR Firmware update status
#2

i am not sure i understand the reasoning for not releasing an update? Not enough engineers? This is a good reason to take advantage of the open source community…especially right now when there are some who might want something to take their mind off things… no need to wait until the end of summer, and continue to lose interest from those who believe in this product…

1 Like
#3

Hi @wegunterjr,

I left some background out of my post. If we had a mechanism for distributing optional firmware updates to users, we would have already released at least one, maybe multiple firmware updates this year. Without that mechanism, we limit the frequency of our app and firmware updates because there are logistical considerations for teachers around updating a classroom full of robots. In the interest of limiting updates and maximizing continuity for our education users, any update has to be thoroughly tested across all supported mobile and desktop platforms to avoid shipping a bug that interferes with classroom activities.

It’s been great to see the variety of open source projects showing up in these forums, either building on top of the public SDKs we’ve developed, or working towards complete alternate SDKs for platforms we never anticipated, and wouldn’t have the resources to adequately support. That was always part of the vision for RVR. Our apps and our firmware, however, have to remain closed-source to protect sensitive IP. Another piece of the timeline puzzle is that we need our docs for new features to adequately support open-source SDK development.

We will ship this update at the earliest possible opportunity, given the constraints of finite resources supporting multiple product lines in the field. Although we’d have preferred to release it sooner, we hope that users will find it was worth the wait. We thank you in advance for understanding, and are hoping you will still build wonders with the robot in the meantime!

-JimK

1 Like
#4

If i understand correctly this will be changing the control method and giving us the option to drive it more like a real RC, so we don’t have to use the same controls as the spheres do?

#5

Driving using the EDU app won’t be changing for now, since there were other priorities for the spring EDU releases and the timing didn’t line up. We will eventually have a way to drive more like an RC car in an app, but in the meantime the firmware will support these new modes, and DIY solutions can take advantage of them.

As an example: in my test setup, I have a dual joystick USB game pad connected to our internal test software sending the commands over BLE. I put linear velocity on the left stick Y axis, and angular velocity on the right stick X axis, with the angular velocity polarity flipped for driving backwards to mimic a car with a steering linkage. This setup feels great to me for manual driving, as it works similarly to a quadcopter in angle mode with a Mode 2 transmitter. Side note: If you are used to another RC vehicle, try to map your inputs to be as similar as possible to what you already know. Otherwise you’ll have a lot of brain retraining to do.

I have something similar set up for tank commands with the left and right velocities assigned to the left and right joysticks, but that’s considerably more difficult to drive manually unless you cap the velocity commands at a low value. I’m guessing it’ll be used more for programmatic driving, taking the place of the raw motor commands in many projects.

This project could easily be adapted to the new commands, and will likely be updated after we ship the firmware: https://github.com/sphero-inc/sphero-sdk-raspberrypi-python/tree/master/projects/rc_rvr

-Jim