Rosrun ubiquity_motor FAILS

ubuntu@Spud:~$ sudo systemctl stop magni-base
ubuntu@Spud:~$ rosrun ubiquity_motor

Welcome to the Ubiquity Robotics Firmware Updater!

Please make sure that you are not running any ROS nodes.

  • sudo systemctl stop magni-base

Note: Updating the firmware requires access to the internet.

Please enter your email address: mike@*****.com
An access token was sent to your email address
Please enter your access token: 3fee6b1272ca8782
What version would you like (press enter for latest):

Updating firmware now. Do not power off the robot. This is expected to take less than a minute.
(‘Encryption:’, True)
Traceback (most recent call last):
File “/opt/ros/kinetic/lib/ubiquity_motor/”, line 425, in
silicon_id, silicon_rev, bootloader_version = send__enter_bootloader(ser)
File “/opt/ros/kinetic/lib/ubiquity_motor/”, line 308, in send__enter_bootloader
File “/opt/ros/kinetic/lib/ubiquity_motor/”, line 250, in send
raise Exception("Packet did not start with valid start byte, instead: " + cstr(start_byte) + " – header: " + cstr(header))
Exception: Packet did not start with valid start byte, instead: <- [] – header: <- []

Update 1:

I tried this command on a raw flash…no apt-get update or any other mod…still fails.

I can get this error if my motor control board is powered off or if there is a serial communications error.
I do not think we tell users they have to have their main board turned on so perhaps we should.

Are you using a standard Raspberry Pi 3 model B+ or some other cpu.
Please supply output from this command ls /dev/tty*

Thank you

Tried with power on. It is believed that we have a major serial com error on our MCB, so not so surprising.

We are using a Raspberry Pi 3 Model B+. It is a replacement as the one shipped with the robot seemed to have com errors.

ubuntu@Spud:~$ ls /dev/tty*
/dev/tty /dev/tty19 /dev/tty3 /dev/tty40 /dev/tty51 /dev/tty62
/dev/tty0 /dev/tty2 /dev/tty30 /dev/tty41 /dev/tty52 /dev/tty63
/dev/tty1 /dev/tty20 /dev/tty31 /dev/tty42 /dev/tty53 /dev/tty7
/dev/tty10 /dev/tty21 /dev/tty32 /dev/tty43 /dev/tty54 /dev/tty8
/dev/tty11 /dev/tty22 /dev/tty33 /dev/tty44 /dev/tty55 /dev/tty9
/dev/tty12 /dev/tty23 /dev/tty34 /dev/tty45 /dev/tty56 /dev/ttyAMA0
/dev/tty13 /dev/tty24 /dev/tty35 /dev/tty46 /dev/tty57 /dev/ttyprintk
/dev/tty14 /dev/tty25 /dev/tty36 /dev/tty47 /dev/tty58 /dev/ttyS0
/dev/tty15 /dev/tty26 /dev/tty37 /dev/tty48 /dev/tty59
/dev/tty16 /dev/tty27 /dev/tty38 /dev/tty49 /dev/tty6
/dev/tty17 /dev/tty28 /dev/tty39 /dev/tty5 /dev/tty60
/dev/tty18 /dev/tty29 /dev/tty4 /dev/tty50 /dev/tty61

Hi Mike,
I suggest we use this thread for resolving serial com problems.
I am re-posting my large serial debug post here now below.

Suggest we stick to serial com since the image and apt upgrade issues are a very different thing and as I mentioned I will be re-testing that myself in case there is some unique rasperry pi hardware out there that in fact is messing up our upgrade.

If you send an email to We can resolve the interactive discussion using email then post back to here any ‘breakthroughs’. This will limit traffic on the forum which is seen and notifies a great many users. Thus we save their inbox.

Here is repost which I may remove from other thread:

Thank you for clarification of setup. The Pi 3 B+ supplied with Magni is an off the shelf unit, not special.

I agree with your thoughts that there is a serial communication problem in it’s current state .

Do you still have the original Raspberry Pi that came with the product and can that operate the MCB? I will assume no but it may be a valuable clue helping to fix this if any Pi can run the MCB right now.

Below is an involved text which i am creating for you but also to form a serial debug page for our docs this is my ‘first take’. You may know a lot of this already but I am writing this for general use.

I will assume you always plug in or out your Pi with magni power off and that you never accidentally had a case where you plugged the Pi in off by one pin. I ask this because we have directly seen that in multiple cases and it will often destroy serial com, sometimes the full Pi. It is easy to do and may be involved.

At this time I am assuming your Pi is directly plugged into the MCB board and you are not doing something where the Pi is only connected to the MCB with jumper wires (an important point but unlikely)

Here are some diagnostic steps to debug serial communications:
Because there is a possibility that the apt upgrade is what leads to this and because you have had other issues with burning the image What I will do is below, tell me if you did something different or if in fact you every tried the current Pi just after image burn and before any firmware upgrade or even apt upgrade. Need to isolate if this is hardware or software with the apt upgrade is my thought.

You can wait till i duplicate your test if you are busy or you can look at these things now.
Here are the steps I will try now

  • Burn to a fresh 16GB MIcro Sd card the 2019-06-19 image and see if communications with MCB works after powerup and after two minutes (some network issues prevent startup of our code for a long time if ntp cannot be contacted, a bug that is being fixed in early 2020).
  • Verify this simplest of setups can talk to the MCB and allow magni to run. This can be done by inspection of ROS topic /battery_state using ‘rostopic echo /battery_state’ and in the output you would see the ‘voltage’ value fluctuate a tiny amount which verifies a live system.
  • If this fails we use minicom by removing the Pi from Magni and connecting the Pi pins 8 and 10 then powering the Pi with a micro USB power supply suitable for over 2Amp current. Then we do a ‘sudo apt install minicom’ and after that the test is to see if we can see characters we type when not in echo mode after running this command ’ minicom -b 38400 -o -D /dev/ttyAMA0’ Also after that works disconnect pin 8 from 10 and ensure you do not see chars (verify echo was off).
  • If you have a working serial interface at this time then a firmware update to the default version (use just an ‘enter’ when asked for revision). Here is the process:
  • If above firmware upgrade to v32 works then do the apt update followed by an apt upgrade and verify we can get the Magni to run by inspection of ‘rostopic echo /battery_state’ as before.

To verify the MCB board firmware is running we look for ‘STAT’ led to blink :
If your power up the Magni can you tell me if you see the left most of the 5 LEDs blink off every 5 seconds or so but is usually on? Then using a clock can you tell me how many seconds it is between blink-offs? It is best to measure 4 or more blinks then divide by 4. Doing this tells me the firmware revision you are running which may be part of this problem.

If you do see the blinks then next I wonder if on a freshly burned image the serial does work but it is after the apt upgrade that things are broken.

If this problem happens with a fresh image and no api upgrade yet then we want to know if the Pi itself has a fully functional serial port in an independent test not involving the magni board.