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 ?
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.
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.
Thank you for your assistance. I went through the documentation on the Ubiquity websites and here is what I have observed.
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.
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.
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.
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.
I did not power off the robot during the firmware update. The STAT light would not light up after the failed firmware update.
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: https://learn.ubiquityrobotics.com/PC_Board_RevId
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? https://learn.ubiquityrobotics.com/firmware-upgrade
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.
Thanks,
Mark
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?
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: https://learn.ubiquityrobotics.com/camera_sensors
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 support@ubiquityrobotics.com Then in the subject it would be best to say ‘Route to Mark for MCB Replacement’.
Myself and my team are also getting this “Firmware not reporting its version” error message when running roslaunch magni_bringup core.launch.
We tried the suggestions made by @rohbotics but the issue persists.
We are using a RaspberryPi4 and have compiled the code for ROS Melodic. We have used colcon bundle to deploy the stack on the Raspbian Buster 64-bit OS.
@bryan_bot Please can you start a new thread for your issue? You are out on an unsupported release and we will try to help but that is a completely different issue than the one on this thread.
Better still if the thread title said ‘Using Melodic we cannot contact the MCB’ or something like that so we know that thread is about trying to get Melodic to work.
The ‘Firmware not reporting it’s version’ is a very high level error that basically is saying ‘The Pi cannot talk to the MCB processor over the serial link’. This can be a great many issues. In the earlier cases in this thread the issues were basically hardware issues.
Anyway, I would like any such issue that comes with use of Melodic or other release we as of yet do not have solutions for to be a separate thread please. It will then be easier to track it’s ‘root cause’ and not mix it up with other issues for serial failures using our supported images.
Thanks, this will help us track this in a way we can find and recognize nicely.
Thanks and stay safe, Mark
