Powering RPI from SpheroRVR - issues with controlling motors

Hi guys,

I’m having issues controlling the RVR motors via RPI if it’s powered up from sphero (regardless if via USB or pins).
When on sphery power supply, RPI does not seem to be able to start motors, LEDs work no problem, when switched to external power source everything works like a charm, is this known issue? Any solution to that?

Hi @szymon, I don’t know what would cause your described symptoms, as all commands are simply packets sent over the UART.
If any of them work they should all work. Can you post complete python scripts that demonstrate the issue?


Actually I’m wrong, controlling LEDs also do not work. I’m also getting low voltage warning on RPI when powered from SpheroRVR. I checked:

  • 3 different cables
  • 2 different RPI boards

Here’s the code I’m trying to run:

# always include from this line <-----
import os
import sys
import time
from random import randint

from sphero_sdk import SpheroRvrObserver
from sphero_sdk import Colors
from sphero_sdk import RvrLedGroups

rvr = SpheroRvrObserver()
# -----> to this line :)

def main():
    """ This program demonstrates how to set a single LED on RVR using the LED control helper.

        # wake up RVR

        # Give RVR time to wake up

        # switch off leds

        # Delay to show LEDs change
        i = 0
        while i < 10:
                led=RvrLedGroups.headlight_right ,
                # randing(0,255) returns a random number from range 0 to 255
                red=randint(0, 255),
                green=randint(0, 255),
                blue=randint(0, 255)
                led=RvrLedGroups.headlight_left ,
                # randing(0,255) returns a random number from range 0 to 255
                red=randint(0, 255),
                green=randint(0, 255),
                blue=randint(0, 255)
        print("program finished")

    except KeyboardInterrupt:
        print('\nProgram terminated with keyboard interrupt.')


if __name__ == '__main__':

Works as expected when powered up from external source, doesn’t when powered from Sphero

The low voltage warnings really aren’t something to ignore, as they can cause your Pi to have hardware malfunctions. I would guess in this case that your UART hardware is not working correctly when powered from RVR due to voltage drop on the USB cable. Since there’s a lot of variability in USB cables, you may be able to get a low enough voltage drop with a really short, heavy gauge USB cable. I’ve always gotten away with using the blue USB C cable that ships with RVR to power a Pi4, and various micro USB charging cables from other Sphero products for a Pi 3B, but YMMV due to component tolerances.

And as a note for future readers of this thread, RVR+ (coming out this fall) has the 5V regulator trimmed up a bit to compensate for some cable voltage drop.

I’ve tried with 3 different USB cables, all of them <10cm. I’m yet to succeed powering RPI from RVR, I honestly don’t think it is possible. At least not for RPI 3B+ (i’ll try 4 once i get one)

In that case, do you have a volt meter to measure from 5V to GND on the UART header? If so, please take a measurement with RVR turned on, with and without a Pi attached via USB.

Maybe in your case there is a tolerance issue or defect on the 5V regulator and the output is low.

Without RPI - 5.1V
With RPI - 5V

Hi @szymon,

There is a known issue on Raspberry Pi with UART baud rates being tied to the system clock rate, which can vary. To rule this out, can you try the following?

  1. Add the line “dtoverlay=pi3-disable-bt” to /boot/config.txt
  2. In your SDK working copy, check out the branch feature/use-tty-symlinks. You can also view the code change here, and edit the SDK files in place if you’re not accustomed to git.

I’m not sure whether a different input voltage can affect the system clock rate, but if the clock rate is varying, the default UART can produce all sorts of different baud rates and interfere with communications to RVR. For more information, see this thread in the Raspberry Pi forums. We’ve tested this change on Pi 3B+ and Pi 4.