RVR connected via UART to Raspberry Pi sometimes doesn't work

I am using UART for Sphero RVR to run this over a Raspberry Pi and if i just use the SSH over Terminal, then it works just fine.

but frequently observe that when I connect VS Code for remote development (Python) which internally uses SSH too, then the communication between the RVR and the Pi is broken… I am running a simple ECHO program to confirm this and it won’t work. I don’t get any response back. Other sample programs either get stuck or fail too.

python3 echo.py
sending echo

This almost always happens around parallel SSH sessions from my findings.

  • Hardware used Raspberry Pi 3A+ powered by RVR’s USB port.
  • Sometimes i see Under voltage reported but it works fine even with the warning
  • Ultrasonic (HC-SR04) connected as per the recommended diagram - but see this issue even without this hardware.
  • No physical wiring changes done when this change is observed.

Usually the workaround is to shutdown the Pi and power off the RVR and start it back again and re-ssh and it just works.

Has anyone seen an issue like this before?

Hi @swarooptg,

The connection to RVR doesn’t use SSH in any way, so I suspect the SSH part is a distraction here.

The low voltage warnings are the result of too much voltage drop on the USB cable between the RVR and the Pi. This can be caused by either a long USB cable or just one with thin-gauge wires. Please try other USB cables and see if you can find one that avoids this problem. If you have a multimeter, you can measure the voltage from GND to 5V on the Pi header to compare cables.

I have read that running the Pi with low voltage warnings can cause intermittent issues that may be hard to debug. Perhaps UART functionality is one of these.

Please also make sure you have our latest SDK. We made some updates on Dec 21, 2021.

If none of these steps resolve the issue, reply back here and we can see about next steps for debugging.

Jim

Also, can you share your echo.py? Is it one of the ones provided in the getting_started directory, or one that you wrote yourself?

Are each of those sessions accessing the serial port? If so, they are interfering with one another.

If session A sends a command the response might be partially received by A and also session B. Neither session gets the complete response in that situation. In both cases the sessions will discard the response or, possibly, hang waiting for a valid response.

Good point Rud, that makes way more sense if there are two scripts running and using the port at once.

I’ve been wanting to explore some solution for sharing the port (i.e. to have an auto-started background listener for RVR shutdown warnings that could politely shut down the Pi), but haven’t gotten around to it yet.

Jim

1 Like

Apologies in the delay.

This is the echo.py code which is just a copy of the example with an extra print statement.
When opening the second SSH connection, no i wasn’t running any program that could confuse the serial port connection.

import os
import sys
import time
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(file), ‘…/’)))

from sphero_sdk import SpheroRvrObserver
from sphero_sdk import SpheroRvrTargets

rvr = SpheroRvrObserver()

def echo_handler(echo_response):
print('Echo response: ', echo_response)

def main():
rvr.echo(
data=[0, 1, 2],
handler=echo_handler,
target=SpheroRvrTargets.primary.value
)

# Give RVR time to respond
time.sleep(1)

print('sending echo')

rvr.echo(
    data=[3, 4, 5],
    handler=echo_handler,
    target=SpheroRvrTargets.secondary.value
)

# Sleep for one second such that RVR has time to send data back
time.sleep(1)

rvr.close()

if name == ‘main’:
main()

I have this same issue on 2 of the RVRs. Both running the latest Raspberry PI OS (Lite) running on a Raspberry Pi 3A+ and the programs are both python. The need to open a new SSH connection is usually because of using VS Code to edit the code on the bot directly. The exact same setup works most of the time. When it doesn’t - it requires restart and reconnection on VS Code.

Is there anyway to verify that the issue is because the serial port and any way to remediate it? I wasn’t using just 1 ssh Mac terminal to run the program and i usually edit the code in VS Code (or use its own terminal feature sometimes).

The programs check for this and I’ve just started using this, so i believe i am already using the latest SDK version.

For the low voltage warnings, i will change the Micro USB Cables for better quality ones so that there is no possible voltage drop. I merely mentioned it as i thought it might be related to that.

An intermittent problem is typical of conflicts with multiple processes running. They work most of the time except for the occasional times they conflict.

My understanding is you are running.the echo program through SSH.

In another SSH using VS Code you are editing the code on the PI? Presumably that is echo, or is it something else?

I don’t work with VS Code or Python so can’t help much there. But since the problem occurs when VS Code is involved I would look at it. While running multiple SSH session shouldn’t be a problem VS Code might be doing something strange. I"ve good software cause problems like that.

Yes, i am using VS Code to actually edit echo.py and use the built-in terminal or a standalone terminal to run the program. But at any point there isn’t any parallel execution of the same program.

Prior to using VS Code, i was trying to use a parallel SSH session to edit in 1 and run in the other. I noticed this issue even in that case. Almost always, this issue starts when opening a second SSH session and the only fix seems to be to shutdown and re-connect again. Not very pleasant.

I have 2 RVRs and both have the same issue observed when running from UART. The bots themselves are perfectly fine when used with the EDU app.

When you tried this on two RVRs, were you using the same jumper wires on both of them? Any time that someone is having trouble with their UART connection to RVR, the first step should really be to try different jumper wires, just in case. It seems to be very difficult to find good ones these days, and all the jumpers I have tend to get damaged easily, often with no visible signs of an intermittent connection. From my own experience, it’s easy to think you’re seeing a pattern of software failures when the real issue is just a bad jumper that only connects some of the time.

Another thing to try is to only restart the Pi, not RVR, when the failure occurs. See if that gets it working again, as that would confirm that the problem is on the Pi side.

Both the RVRs we separate sets of jumper cables. Based on my experience with this issue, it has something to do with the software as the issue fixes itself if i were to power off the RVR with the button.

I have restarted just the Pi without the RVR and this usually does not work and requires the RVR to be powered off and switched back ON again.

Well, now this is sounding more like a possible firmware bug. Can you do the following test as a final confirmation:

  • Power the Pi from a separate USB power source, not RVR.
  • Do whatever you need to do to reproduce the failure (with clear documentation of all steps taken)
  • After the failure occurs, power cycle only the RVR, not the Pi.
  • Test whether the issue is resolved.

Note: disconnect the power from the RVR to the Pi when doing testing powering the Pi from another source. May not be absolutely necessary but could introduce other issues or possibly back feed the RVR.

Well, now this is sounding more like a possible firmware bug. Can you do the following test as a final confirmation:

  • Power the Pi from a separate USB power source, not RVR.
  • Do whatever you need to do to reproduce the failure (with clear documentation of all steps taken)
  • After the failure occurs, power cycle only the RVR, not the Pi.
  • Test whether the issue is resolved.

@Sphero_JimK I have tested these steps where i have powered the Raspberry Pi with an external power sources and power cycled RVR and the issue persists… No change.

The issue is very random and sometimes the echo continues to work and at other times, even when RVR powers the Pi and i just do a fresh SSH session, the echo also does not work.

Do you suspect any firmware defect and How can i help get this resolved?

rmerriam

6d

Note: disconnect the power from the RVR to the Pi when doing testing powering the Pi from another source. May not be absolutely necessary but could introduce other issues or possibly back feed the RVR.

Thank you, i did ensure this when testing with an external power source. There was no difference in the behavior.

If it persists through a power cycle of RVR then the issue is definitely on the Pi side, not the RVR firmware. I don’t use VS Code so I don’t know how you could go about any additional troubleshooting there.

I normally SSH into the Pi with Putty, and I have the Pi file system mapped as a network drive with sshfs-win. That way I can edit in Sublime Text or any other editor on the Windows side. I’ve never run into any issues doing this. You may want to try something like this instead of VS Code.