LCR Electronics Troubleshooting - directedmachines/customer-support GitHub Wiki

Table of Contents

Overview

This page covers diagnosis of low current electrical and electronics components.

USB Port Topology

The USB topology is like a tree, and the ports further down the branches have longer addresses based on where the earlier hubs are plugged in.

USB Topology Tree

Pi

Pi 4 USB Topology

Location USB Path Segment Full Path Device Tape Colors
Pi Top Left 1.3 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0 Pico Tray Pink - Red
Pi Bottom Left 1.4 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0 USB Hub 1 Pink - Brown
Pi Top Right 1.1 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1:1.0 Caster Camera Pink - Blue
Pi Bottom Right 1.2 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.2:1.0 Axle Camera Pink - Green

Pluggable 60W USB Hub

Pluggable 60W Hub Topology

Hub 1

Assumes Hub 1 plugged into Pi Bottom Left (1.4)

Location USB Path Segment Full Path Device Tape Colors
Port 1 .3.3 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.3.3:1.0 Aux MC No Tape
Port 2 .3.2 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.3.2:1.0 Left MC No Tape
Port 3 .3.1 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.3.1:1.0 Right MC No Tape
Port 4 .3.4 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.3.4:1.0 Pico Brain Brown - White
Port 5 .2 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.2:1.0 USB Hub 2 Brown - Yellow
Port 6 .1 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.1:1.0 GPS Brown - Blue
Port 7 .4 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.4:1.0 Speakers Brown - Green

Hub 2

  • This assumes Hub 2 is plugged into Port 5 of Hub 1 (1.4.2)
  • Note that video devices show up as /dev/v4l/ rather than /dev/serial/
Location USB Path Segment Full Path Device Tape Colors
Port 1 .3.3 /dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.2.3.3:1.0 Left Side Camera Yellow - Green
Port 2 .3.2 /dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.2.3.2:1.0 Right Side Camera Yellow - Red
Port 3 .3.1 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.2.3.1:1.0
Port 4 .3.4 /dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.2.3.4:1.0 Dock Camera Yellow - Blue
Port 5 .2 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.2.2:1.0
Port 6 .1 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.2.1:1.0
Port 7 .4 /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4.2.4:1.0

Connectivity

Connectivity Overview

The LCR is connected to the internet through LTE using a modem (pepwave/peplink) and sim card. The LCR also broadcasts a local wifi connection that allows operators to connect locally but does not provide connected devices access to the internet/LTE signal.

Operators can connect to the robot UI either through a VPN + the LTE connection OR through the local wifi connection broadcast by the LCR.

Wifi

No Wifi signal

No Wifi signal: Symptoms

If the WiFi signal from the robot is not broadcasting, the robot CPU (Raspberry PI) is likely not powered on. This could also be caused by a bad antenna/weak signal, or by an improper hotspot configuration.

No Wifi signal: Fixes

  • Ensure the Pi is powered on.
    • If not powered on but lights are on, the pi may have been intentionally shutdown. Unplug and replug the pi usb-c power cable to reboot.
    • If no lights are on check for a wiring fault (loose wiring, short, battery connector disconnected, busbar connector disconnected).
  • Ensure the wifi antenna is properly connected to the Pi SMA connector and insulated with electrical tape, and that the small end is properly connected to the pi board (LINK IMAGE HERE). Put your device very close to the pi and see if there is a weak signal.
  • SSH into the robot and run ~/dCentralizedSystems/cap-provisioning/pi/scripts/install-hotspot.sh with <HOTSPOT_NAME> and <HOTSPOT_PASSWORD> as arguments to reinstall the wifi hotspot.

Wifi visible, can't connect

Wifi visible, can't connect: Symptoms

Wifi network is seen on phone, unable to connect when selecting the wifi network.

Wifi visible, can't connect: Fixes

  • Ensure Wifi password is correct
  • Ensure the wifi signal strength is sufficient. Move device near the pi and retry.
  • SSH into the robot and run ~/dCentralizedSystems/cap-provisioning/pi/scripts/install-hotspot.sh with <HOTSPOT_NAME> and <HOTSPOT_PASSWORD> as arguments to reinstall the wifi hotspot.

Wifi connected, UI not Loading

Wifi connected, UI not Loading: Symptoms

You can connect to the wifi network but the UI does not show up when you try any of the following URLs

Wifi connected, UI not Loading: Fixes (Ensure Modem is healthy and PI is active)

  • Ensure the url is correct (192.168.50.10:8000, 192.168.8.100:8000 or edge.directedmachines.com:8000). If the edge.directedmachines.com url is not working there may be LTE connectivity issues see: LCR Electronics Troubleshooting - No LTE connection
  • Runtime may be syncing and rebuilding. You can wait ~2 minutes or SSH into the robot and tail the logs (tail /var/log/syslog) to see if it is rebuilding.
  • Check robot status in Soracom. If online, the problem is either with the Pi4 or the modem to Pi4 connection. Attempt to power cycle the Raspberry Pi4. To do this, unplug the PI4 USB from the USB Station, then re-plug it in . Screenshot from 2023-10-09 17-04-35 (1)
  • The CAP service may be disabled. Run top and see if a "java" service is running. If not, start the runtime with sudo systemctl start dcentralizedcaphost.service
  • When connecting to the wifi network it may warn for you to "use this network as is" if you don't select this you won't have access to the UI. Forget the network and reconnect.

Cellular Internet

Pepwave MAX BR1 Modem Resources

AGT UI / Satellite maps will not load

If the modem is not connected to a cell network:

  • it can not publish telemetry ( a yellow warning icon will be shown in fleet management)
  • AGT UI will not load satellite images in google map view and will be in offline mode
  • The edge.directedmachines.com:8000 URL may not work either (use http://192.168.8.100:8000 instead)

Abrupt loss of connection during remote sessions

If the robot has solid connectivity when stationary, but connection is lost when active, there is likely a poor electrical connection

  • check the power leads into the modem power connector. Make sure everything is secure and tight from modem to 12V bus bar
  • check the SMA connectors (gold connectors on modem) connecting antennas to modem

If the robot is in an area with poor connectivity and is often losing connection, follow the Poor Connectivity Area guide below

No LTE Connection: Fixes

  • Ensure the antennas are intact and properly connected to the modem, the ethernet cable connects the modem to the pi, and the modem is powered and status lights are green.
  • Unplug and replug the ethernet cable to the pi, SSH into the robot
    • Run ping github.com from command line to test connectivity
      • If you can ping github.com, it means connectivity has been restored and you should restart the CAP runtime and reload the AGT UI.
    • Ensure eth0 IP is 192.168.1.100 when running ifconfig
  • Directly connect laptop to modem using ethernet cable and test connectivity (ping github.com from command line).
    • When connected by ethernet can log into the modem at 192.168.8.1 and check the settings are correct (follow instructions for #003737 - DM (A) Advanced Cellular Connectivity Kit)

The Pepwave modem has a WAN RSSI page that will display the signal strength during the past hour. The support team can help get that information: RSSI Long RnD on top of side - 607pm S start - 609 NE - 611 NW - 614 S end

Before taking any further actions contact a software team member on slack and ask for advice.

  • Power cycle the modem (unplug and replug power cable) and wait 5 minutes for it to boot back up.
  • Could be related to bad USB peripherals.

Poor Connectivity Area

If the robot is operating in an area with poor connectivity, it might fully lose connection with the fleet and require a modem reboot to bring it back online.

Rather than rebooting the modem in person, the modem can be scheduled to reboot daily by following these steps:

image

  • To confirm the reboot is scheduled, return to the modem dashboard page. There should be a reboot scheduled notice at the bottom of the page

image

Rebooting and Resetting

Reboot

A modem reboot can be done by following these steps:

  • Connect to the modem wifi and access the dashboard
  • Go to the System page, select Reboot in the options on the left, and click Reboot. Ensure the proper Firmware is selected for the reboot

image

Reset

A full modem reboot can take upwards of 10 minutes to complete. If only a reset is necessary, it can be done by following these steps:

  • Connect to the modem wifi and access the dashboard
  • Go to the cell connection details page, and click the question mark in the top right to find the option to reset

image

Modem Continuity Test

The frame of the modem should be isolated from the LCR tray. To ensure isolation:

  • Use a multimeter on continuity mode to test for continuity between the modem and the tray. Continuity should not be found
  • If continuity is found, use velcro or electrical tape to ensure no part of the modem touches the metal tray
  • Continue to isolate the modem and test with the multimeter until no continuity is found

Speakers

The speakers emit a tone when autonomy is about to start. If no sound is heard,

  • check that both the USB tail is connected to the 7 port hub (its the power supply for the speakers) and the 3.5mm audio male connector is inserted all the way into the PI audio port
  • the sound properties Java runtime file has proper permissions

The sound properties file is normally configured during auto provisioning but it can be made writable using these steps

  1. SSH into the robot
  2. change permissions using this command: sudo chmod 777 /etc/java-8-openjdk/sound.properties
  3. restart CAP runtime

Charging State

The telemetry details page on a robot provides metrics relating to solar and AC charging input. The wattSecs metric, reported by the self-monitoring-task-service, reports the current power draw on the robot.

  • a negative watt-seconds number indicates power is going in the robot, it is charging
  • a positive number means that energy is being used at a rate higher than input (charge) energy
  • a number between -50 to -500 means we are solar charging
  • a number between -700 to -5000 means we are AC charging (and potentially also solar charging

You can find this number in two ways, on the robot itself. You can also find charge rate and time to full, by clicking the battery icon, in the telemetry details page

Screenshot from 2022-11-18 11-58-13 Screenshot from 2022-11-18 11-58-25

Telemetry Details Dashboard UI

Please use the Fleet Management UI, data details page for the robot and follow the same instructions as below to search stats. You do not need access to a robot to check any of its metrics, you can do so through your web browser and our fleet management

  • Touch the "bars" icon on the lower left corner to bring up the telemetry dashboard
  • Type "wattSecs" in the "Inspect Telemetry" -> "Search stats" input box

Data Multiplexing Service Stream

You can view the metrics directly from the data multiplexing service

  • Touch / Click the "gear" icon on lower left corner of screen in Manual UI
  • Type "multi" in the service input box
  • Select the "stream/text" button for the service entry
  • Search for "wattSecs" text

Solar Troubleshooting

If you do not see a negative wattSecs number, robot is not charging from the sun. The following steps make sense if solar is expected, so during the day, cloudy or sunny, with the solar panel clean and not shaded

  • Make sure panel is receiving solar radiation
  • E-stop robot
  • Open panel
  • Verify panel + and - cables going to inside of high current electronics (HCE) tray are connected to the Solar Charge Controller (SCC)
  • Use a Clamp current meter on the positive + cable from solar panel to determine if current is flowing
  • Check connections from SCC to battery bus bar
  • Check lights on solar charge controllers
    • Alt SCC Genasun: Should be green or flashing green
    • DM SCC board: Should be flashing green. If the "solar fault" LED is flashing red, press the small black "reset" button just below the DB9 connector and restart the robot from the UI (video here).

If no charging is reported, this could mean the pico tray is not reporting.

  • Look at the pico-controllers/tray-4260 stream in the CAP UI
  • If the stream is not updating, reboot the robot to restore the pico

AC (shore power) Troubleshooting

The robot will charge from AC if the robot onboard charger unit is connected through an extension cord to an AC 110V circuit (or 240V). If the wattSecs is not indicating a number of 700W or more of charging:

  • Make sure AC extension cable is connect to robot side plug and to AC plug on wall / infrastructure
  • Verify charging unit inside robot has Green blinking LED, or Yellow LED on. If robot has new batteries, unplug extension cord, wait 1 minute, plug back in, check wattSecs (sometimes charger stops charging, the first time, on new batteries)
  • Verify AC circuit provides current - use a AC current clamp meter to measure current flowing from AC plug. Sometimes circuit breaker trips

AC (Renogy 48V inverter) Troubleshooting

  • Make sure AC extension cable is connect to robot side plug and to AC plug on wall / infrastructure
  • Make sure Renogy is powered on once it is plugged in (using remote switch)
  • If circuit trips need to check the max current setting (Setting #28). It depends what the circuit breaker is rated for, (MaxBreakerCurrent*120V)/58V = Current Setting. 20A is good if we're limiting it to 10A from the outlet. 30A is better if the outlet can handle 15A.

Pi Troubleshooting

Pi LED Blink Patterns

Power LED (Red)

  • The power LED should be solidly lit. A blinking power LED indicates possible Pi under-voltage. No light indicates the Pi is not receiving power.

Activity LED (Green)

  • If the Pi has an SD card inserted, the activity LED should blink in an irregular pattern. A regular pattern of short and/or long blinks indicates a possible failed or corrupted SD card.

Pi Under-Voltage

  • Can manifest with "Drive MC sample late", "AUX MC sample late", "MC Disconnected", or "E-Stop engaged" alerts
  • Check kernal log for:
    • "Nov 6 15:56:54 LCR24ZS0 kernel: [975264.239616] Under-voltage detected! (0x00050005)",
    • "Nov 6 15:56:58 LCR24ZS0 kernel: [975268.409668] Voltage normalised (0x00000000)",
    • "Nov 6 15:59:47 LCR24ZS0 kernel: [975437.251767] usb 2-1: USB disconnect, device number 33",
  • The 5V supply to the Pi is unstable. The issue seems to get worse the more USB peripherals are plugged in
  • To fix, install the 004679 Tray Controller Board, replacing the currently installed tray board
    • If Tray Brain is not available, recommended to unplug all non essential USB peripherals (analog speakers, unneeded cams, etc)
    • If Tray Brain is already installed, try following the Pi to Tray Brain USB Failure guide below.

Pi to Tray Brain USB Failure

  • Can manifest with similar symptoms to the Pi under-voltage symptoms listed above, or continuity symptoms listen in the Continuity and Shorts Troubleshooting wiki including the following:
    • Under-voltage alerts in the Kernel log
    • A sudden Pi reboot or restart
  • Diagnose by wiggling the USB C to USB C cable connecting the Pi to the tray brain. If this causes Pi LEDs to flicker or shutoff, the USB cable needs to be replaced.

Continuity and Shorts Troubleshooting

Information on testing for continuity between various electronics and components can be found here