Motor_node fails with 'Firmware not reporting its version'


Lately I’m facing issues with motor_node. The logs of magni_base shows " Firmware not reporting its version". I’m using the Ubiquity Robotics Ubuntu image. One thing I did is enabling the uart to use for debug serial port and later I came to know that the default serial port is actually used by the motor controller(My bad, I should have read the code before trying that out). After looking at the code, I tired to revert all the changes I had done to enable the debug serial port. But I’m unsuccessful, the motor node now fails with “Firmware not responding its version”. Can some one point me what configuration I’m missing to the serial port to properly work with motor_node ?

Here are the logs from systemd:

As you have figured out “Firmware not responding its version” means communication with the motor controller failed.

Make sure that your /boot/config.txt matches this

And that your /boot/cmdline.txt matches

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=${FS} elevator=deadline rootwait quiet splash plymouth.ignore-serial-consoles


Yes, that was the first thing I did. I made sure the cmdline.txt and the config.txt are same as per the ubquity robotics ubuntu image. I cross verified the configurations, file permissions with a working magni. Also I checked that if any process is using the ttyAMA0/ttyS0, but no process is using those tty ports.

I swapped the SD card with new image and motor node starts working. But which is confusing me is what could be the missing configuration which made the motor_node fail. It would be nice if you can point me to the correct direction, so that I can try to figure out the source of the issue.

Said that, with the new image the magni motor control worked perfectly. But once it happened that the motors are no more moving. Only rebooting the system helps to control the motors back. While this issue happens right side of the motor slightly vibrates.(Not sure why it happens). I made sure the batteries are having enough juice.

I saw few others too face similar issue with motor control, this makes me to worry a bit.

Hi all,

I have two magni robots and one of them just had the same issue and cannot move. I have check everything proposed by rohbotics and it all looks fine. It worked perfectly fine before yesterday. Here is a screenshot of the issue, please advise.

Here are a few things starting with most common:
Please look here first

If not the battery verify the SIN and SOUT leds blink and the MCB ‘STAT’ led or STATUS has a drop out quick blink every 4-6 sec.

Only rev 5.2 or later MCB boards will have the SIN and SOUT leds that are very valuable for this sort of debug.

Hi Mark,

Thank you for your assistance. I went through the documentation on the Ubiquity websites and here is what I have observed.

  1. On my robot’s MCB there was only five lights, no SIN and SOUT in the middle of the board . All lights would light up, with the STAT lighting up periodically.

  2. I checked the battery’s voltage to be 26.7V, I also checked the connection from the battery to the mother board and everything seemed fine.

  3. The wheels had some resistance when the robot was turned on. However when, I pushed the red power button the wheel would move forward a bit.

  4. I then decided to do a firmware update, which failed. It asked me for my email, then sent me a key code, but once I entered the version it prompted this error. I did it again and tried to press enter for the version, same error.

  5. I did not power off the robot during the firmware update. The STAT light would not light up after the failed firmware update.

Best regards,

We have been catching up after the Christmas and New years break, sorry this slowed down this reply.

The most likely original issue is that serial from the Host Pi computer is not able to get to the processor on the MCB. In pre rev 5.2 boards this is a failure mode we have seen before. We added the LEDs of SIN and SOUT to easier debug that sort of failure but you don’t have those.
I don’t know for sure which of the MCB boards you have but if it is not labeled with big white silkscreen on the left edge of the board it is rev 5.1 or earlier. The revision is still on the far left but very hard to read due to dark blue silkscreen. Because of this we made a page to identify the early board revs here:

A second failure mode came about because of a baud rate bug which we have addressed in current images but did exist in earlier Pi images. This is not very likely but may be related.

The current state you report of the MCB no longer even blinks it’s ‘STAT’ led I have seen one other time related to a firmware upgrade. Were you following the firmware upgrade process outlined on this page?
it is key to have to disable the host Pi using ```
sudo systemctl stop magni-base

Please report back to me your MCB board revision and we will get you going after that.  

Also It would help to tell me that you said everything was working fine then stopped. Did it stop due to any sort of hardware change at all?
Please also tell me the version of the Raspberry Pi. Did you change the Pi to a Pi4 by any chance?
Was there any working on the hardware that happened prior to the ‘suddenly not working’ situation?

Hi Mark,

Once again thanks for helping. I have the rev 5.0 board for both of the robots that I have here. Probably looking to upgrade at some point in time.

The first time the robot’s wheels stopped was after I tried to connect the sonar board on it. I have a pi3 connected to this board.

I have also followed the firmware update page, which led me to the error I previously posted. I had disabled the host pi with the “sudo systemctl stop magni-base” command as stated on the page.


It is more than critical that the red battery main power lead be disconnected for any hardware changed and especially the install of Sonar board. So I assume you followed the instructions for Sonar board here:

Anyway, please contact me at this time so we can get your robot fixed and lets deal with that by you sending an email to Then in the subject it would be best to say ‘Route to Mark for MCB Replacement’.

Thanks for the fast reply.