Let's not Reinvent the Wheel...
First things first.... Is your firmware up-to-date?? Connect your RVR+/RVR to the Sphero Edu app to make sure it has the latest firmware.
I’ve hooked up my board, followed a programming example and executed my program, but nothing is happening.
Is RVR+/RVR in Deep Sleep?
Deep sleep is the same as being powered off, and power output from RVR+/RVR is also disabled. Be sure you’ve pressed the power button, and observed RVR's LED lights power on before you attempt to execute your program.
Is RVR+/RVR in Soft Sleep (same as being on, but most functionality disabled)?
Soft sleep is the equivalent of RVR+/RVR having a screensaver. If your RVR+/RVR pulses purple every 10 seconds that means it’s in soft sleep. You will need to “wake” RVR+/RVR through either the SDK’s wake() command, or connect via the Sphero EDU app. You will see RVR's LED lights power on once it’s awake.
Is the 4-pin UART cable plugged in correctly?
It’s advised that you refer to your specific board’s pinout diagram before connecting to RVR+/RVR. Be sure that your board’s RX pin is connected to RVR's TX pin, and your board’s TX pin is connected to RVR's RX pin.
My program isn’t compiling
Did the setup script included in the SDK complete successfully? It’s possible the SDK setup scripts didn’t complete properly. Try re-running the setup script and look for any errors during the installation of our toolchain.
Have you installed all dependencies (libraries your program needs to run)? Depending on which external libraries you are using, they may require updates to your board, and/or version of python.
I issued RVR+/RVR a drive command, but it stops moving after a short period.
RVR+/RVR drive commands (drive_with_heading and raw_motors) are designed to timeout after 2 seconds when issued once. If you want RVR+/RVR to drive continuously, be sure to issue the drive commands in an ongoing loop.
My RVR+/RVR stops responding when running my micro:bit program.
It’s possible to flood the serial port with too many commands when operating RVR+/RVR through an external board, such as a micro:bit. This is especially true if your program executes in an infinite loop. Be sure to include a sleep command at the end of your loop of at least .1 seconds (i.e. sleep(100)).
Another possibility is that your code produced a firmware error. Make sure the values you’re sending are within the specified ranges.
I can't seem to get RVR+/RVR and Arduino to work together...
The issue may simply be that your USB cable is too long. Data transmissions of any kind, especially over a thin wire, are unreliable, so we recommend that you keep the length of your USB cable as short as possible. We've found cables of 12in or less to be best, but have had fairly consistent success with 2-3ft cables, as well.
When I use a heading of 0˚ to drive RVR+/RVR, it turns around. Why?
The current 0˚ heading on RVR+/RVR may not be the direction it is currently facing. Use the reset_yaw() command to set RVR's 0˚ heading to the direction it is currently facing.
My RVR+/RVR entered soft sleep, but when I drive with heading, it is still turning in unexpected direction, as though the yaw wasn’t reset.
The yaw is only reset if RVR+/RVR enters deep sleep, or the command reset_yaw is explicitly called.
Broadcasting with RVR+/RVR does not seem to be working; my other robot does not follow RVR+/RVR even though RVR+/RVR is set to broadcast on the same channels that my other robot is set to follow on.
Be sure that your passing in far_code and near_code in the correct order to start_robot_to_robot_infrared_following.
Make sure that, whenever a call to start_robot_to_robot_infrared_following has been made, a call to stop_robot_to_robot_infrared_following is made afterwards. If not, this messes up the serial port on RVR+/RVR (somehow) and following calls to start_robot_to_robot_infrared_following WILL NOT WORK w/o rebooting the pi.
My RVR+/RVR isn't streaming the sensors I enabled.
If rvr.wake() is called followed by rvr.enable_color_detection(...) etc., it may be that color detection / handler is actually never enabled / registered because RVR+/RVR didn’t get enough time to wake up entirely. In this case, it’s required to call asyncio.sleep(...) before enabling any sensor streaming / registering any handlers. Obviously, if RVR+/RVR is already awake when starting program, this problem does not arise.
My RVR+/RVR isn't reading colors very well.
The RVR+/RVR color sensor window is sensitive to dirt/fingerprints/smudges. Go ahead and give it a good wipe with a soft cloth (like one for glasses or computer screens) and your RVR+/RVR should be good as new!