Cannot run teleop_twist_keyboard

1

Hello, i tried running my magni after installing the new MCB but seems like my magni cannot do teleop_twist_keyboard and get “Waiting for subscriber to connect to /cmd_vel”. Checked rostopic list and there’s /cmd_vel. I also checked rosnode list and see the motor node.

But then I tried running sudo apt upgrade and got this issue which is multipath service.

Reading package lists… Done
Building dependency tree
Reading state information… Done
Calculating upgrade… Done
The following packages were automatically installed and are no longer required:
libxmlb1 python3-rosdistro
Use ‘sudo apt autoremove’ to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up multipath-tools (0.8.3-1ubuntu2.1) …
Job for multipathd.service failed because the control process exited with error code.
See “systemctl status multipathd.service” and “journalctl -xe” for details.
invoke-rc.d: initscript multipath-tools, action “start” failed.
● multipathd.service - Device-Mapper Multipath Device Controller
Loaded: loaded (/lib/systemd/system/multipathd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2023-02-02 10:14:32 +08; 64ms ago
TriggeredBy: ● multipathd.socket
Process: 9227 ExecStartPre=/sbin/modprobe -a scsi_dh_alua scsi_dh_emc scsi_dh_rdac dm-multipath (code=exited, status=1/FAILURE)
Process: 9228 ExecStart=/sbin/multipathd -d -s (code=exited, status=1/FAILURE)
Main PID: 9228 (code=exited, status=1/FAILURE)
Status: “configure”

Feb 02 10:14:32 ubiquityrobot modprobe[9227]: modprobe: WARNING: Module scsi_dh_rdac not found in directory /lib/modules/5.4.51-v7l+
Feb 02 10:14:32 ubiquityrobot modprobe[9227]: modprobe: WARNING: Module dm-multipath not found in directory /lib/modules/5.4.51-v7l+
Feb 02 10:14:32 ubiquityrobot multipathd[9228]: --------start up--------
Feb 02 10:14:32 ubiquityrobot multipathd[9228]: read /etc/multipath.conf
Feb 02 10:14:32 ubiquityrobot multipathd[9228]: path checkers start up
Feb 02 10:14:32 ubiquityrobot multipathd[9228]: DM multipath kernel driver not loaded
Feb 02 10:14:32 ubiquityrobot multipathd[9228]: DM multipath kernel driver not loaded
Feb 02 10:14:32 ubiquityrobot systemd[1]: multipathd.service: Main process exited, code=exited, status=1/FAILURE
Feb 02 10:14:32 ubiquityrobot systemd[1]: multipathd.service: Failed with result ‘exit-code’.
Feb 02 10:14:32 ubiquityrobot systemd[1]: Failed to start Device-Mapper Multipath Device Controller.
dpkg: error processing package multipath-tools (–configure):
installed multipath-tools package post-installation script subprocess returned error exit status 1
Processing triggers for libc-bin (2.31-0ubuntu9.9) …
Errors were encountered while processing:
multipath-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

Does anyone knows how to fix this problem ? Thank you.

2

Hmm it’s possible that the motor node doesn’t crash but posts some errors. You could try doing a rosnode kill -a and then start the robot manually with roslaunch magni_bringup base.launch which will show you the live logs in the terminal.

I really wouldn’t recommend that on any system that’s been running for a while, the longer you go after first boot the larger the chance it just messes something up by upgrading some dependencies to a version that’s no longer compatible with other packages, breaking your install in various fun ways.

I’d suggest finding another SD card or do a readback your current install, then test with a fresh base focal image so you can eliminate any problems on the software side until you can confirm that the hardware works.

3

Sudo systemctl disable multipath-system
Sudo apt remove multipath-tools

Sudo apt update
Sudo apt upgrade
Rosdep update

On workstation

See if you can

Rostopic echo /battery

4

If you can’t echo /battery, but can see it in rostopic either you aren’t talking to the mcb or there is a network issue between the workstation and robot.

You might want to look in .Ros/ logs or in dmesg to see if you are connecting to the mcb.

5

I think it best to start with basic debug in this case. I am unable to attach the file. Send an email to support@ubiquityrobotics.com and in subject say ‘Attention Mark’

I will paste text here instead now which may be a bit of a mess but lets try:j
Diagnostics For MCB & Raspberry Pi Basic Health Rev-20220921

This document attempts some step by step troubleshooting to decide of the MCB or the Raspberry Pi is bad. It is critical to be very sure the battery is at 24V or above so this is not just a battery problem.

Our main debug info is here: Verification - Magni Documentation

The #1 issue we see for failures is batteries have discharged so the robot starts having different types of problems so please focus on the ‘Evaluating The Batteries Of The Robot’ on above page.

CHECK 0: Verify The MCB Revision And If It Has A recent 2021 Mod

The Raspberry Pi4 was found to need slightly higher voltage. Boards made before 2022 need to have had a modification done for 5.1V battery. See if in black felt pen on the right of the MCB if you see a short note that in it has ‘5.1’. Please report back to us if this is present in any trouble report.

CHECK 1: Verify The 5 Onboard Power Supplies Of the MCB Are Ok

If the 4 closely spaced power supply leds are all on in a bright way and the 3.3V led up high and to the left is also on in a bright way we can say the power supplies on the MCB seem ok. If not, bad MCB.

CHECK 2: Verify The MCB processor is running

If all 5 power leds are nice and bright then we look for the ‘STAT’ led to it’s right of the 4 power supply leds is doing a brief blink to off state then back on every 4 seconds sort of time. If you do not see the STAT led do any blinking briefly off the MCB firmware is damaged or the MCB processor is bad. IF the STAT led does not do it’s blink-offs the MCB is to be replaced.

CHECK 3: Verify The MCB is sending Status To The Raspberry Pi Host

The ‘SOUT’ led near top center of the MCB board must ALWAYS be blinking very fast. If it is not blinking fast you must do more troubleshooting on the next page.

CHECK 4: Verify The Raspberry Pi Is communicating With The MCB Board

The ‘SIN’ led near top center of the MCB board must ALWAYS be blinking very fast once the Raspberry Pi has fully booted up. If you do not see SIN blinking wait 5 minutes just in case it is a very long bootup. If it is not blinking fast you must do more troubleshooting on the next pages.