No response From Motor

Good morning folks,

I’m having a new issue, with a recent magni-board recieved - no response from the motors.

Here is what I have found so far:

  • magni board and magni motor is powered (I can confirm the blue and red power LEDs are on, and respected lights on the board match the other boards we have).
  • “rostopic echo motor_power_active” returns a False (Normally always True).
  • I have changed the wheels, and same symptoms.
  • There appears to be no power reaching the wheels, as there is little no resistance on the wheels (normally when powered, you can feel the movement resistance, if you attempt to move by hand).
  • I have upgraded the firmware to v40 (from Dec 2020) - This is the firmware we always use.
  • Motorboard version is 5.3
  • I have compared all of the wiring to other boards, and it appears to be identical.

Any thoughts on what could cause this behaviour? It really appears as though no power is getting to the motors at all.

Thanks,
Kris

More info to add:

  • Battery Power is 26.5V
  • The small blue LED on the board that reads “LED 24V Motor” is powered on.

One of the lights should blink periodically (like briefly every 6 seconds) is that happening?

Did you get a response that the firmware loaded successfully?

Confirmed - firmware loaded succesfully.
Confirmed - status light is blinking every 6 seconds.

You have reported the lower right blue led of ‘24V_MOTOR’ is on so that is good to know.

This will be a problem, maybe our main clue.
The blink rate for v40 is 5.75 sec/blink for the released version which basically matches your observation of ‘about 6 sec’. What really matters in firmware daycode of course.
The ‘official’ v40 will have in ‘rostopic echo /diagnostics’ a firmware date code of 20201209 but I am thinking that is not our problem but still, check that to be complete here.

Not yet stated but verify the 2nd led from left in row of leds that says 12VM is on and in fact verify all 4 leds to the left are on solid and you have already said the right hand LED, ‘STATUS’ is looking normal at 6 sec per blink.

There are some new blink codes in the firmware that show up on the ‘STATUS’ led that may offer some clue as well.

This page: Verification | Learn Ubiquity Robots and ROS in ‘Part 5’ shows some new blink codes that may show up right after power-up so see if after you power up OR you push the ‘RESET’ switch on the MCB that is 5cm below the left, ‘AUX’, 4-pin power jack. Verify that you only see the normal blinks happen and you don’t see a sequence of blinks described on verification page.

Next I would like you to try our recent ‘motor selftest’ feature. See if you can find a standard 0.1" jumper commonly used for option switches and so on on PC boards. If you have such a jumper turn off the magni and BEHIND the MCB board just about in dead center of the board put that jumper on the middle to lower pin only accessable from battery compartment. This is P706 and if the TP4 lower pin is shorted to the center pin (ground) the v40 firmware will do a selftest, part of which is to try to turn the wheels on its own. If you put the robot on a block so wheels don’t hit ground, you will if it works have the wheels rotate one way then another (it is a small rotation of around 10 degrees each way).

Lastly for sake of being complete we want to inspect all wires from each motor cable going into the back of the MCB and tug wires slightly to verify they really are screwed in nicely. This is 9 wires per wheel.

Here are the answers to your questions:

  1. Confirmed blink rate of ~6 seconds.
  2. Confirmed: echo /diagnostics has a firmeware date code of 20201209
  3. Confimed all 4 leds on the left are on and solid.
  4. The blue led near the top labled 3.3V is powered on.
  5. The blue led near lower left corner labled 24V power on, is ON
  6. Both blue and Red large LEDs are ON, on the switch board.
  7. Motors can easily be moved (ie. no resistance)
  8. SIN and SOUT LEDs are blinking rapidly.
  9. Motor LED goes off when emergency power switch is pressed (red button).
  10. I’ve checked the “echo diagnostics” - and it is identical to a “working magni”.

Finnally to confirm there was nothing odd with the software, I took an SD card out of a working magni - and the same behaviour occured (so not a software issue).

Hope this helps!
Kris

Thanks for the detailed report. I suspect two things so far:

  1. Clearly you are getting the system to think that there is no motor power as that was your indication reported for ‘motor_power_active’. This remains the top clue.

  2. the second possibility is the firmware is getting illegal wheel encoder readings and this makes the firmware not operate the wheel drive properly.

  3. You may have a ‘signature’ in our rosout.log file that indicates you have hit the rare ‘baud rate bug’ that we thought we had addressed in changes in our ubiquity_motor node that may only be on our most recent image which is here: Ubiquity Robotics Downloads and is the top one from 2020-11-07. Let us check for the fault first and I must verify that image has the proposed fix for the serial bug which it may not yet because this is super rare and we thought it was only on a custom image we made for some other customer.

  4. Some as yet unknown hardware issue

So I am going to address if it is #3 first on your end and I will look at #1 because I have to fake out the board to get that to happen but it may be your issue.

Do a ‘tail -f /home/ubiquity/.ros/log/latest/rosout.log’ This is supposed to be very idle with only a couple messages every minute but if it is pounding out a serial error over and over it is very likely the serial bug which does seem to follow hardware so changing the image to the same image would not fix this.

Also I have not asked you are you were using a Raspberry Pi 4 which is the only type CPU we have seen this serial baud rate bug on so far although it was a custom image.

If we cannot resolve this soon then I may have to get another board sent to you but try the above please first.

Now I feel that #1 is our top choice as I just simulated it and we do not run the motors if this line is not sensing motor power. I simply wanted to confirm on rev 5.3 that would be true, it is.

The most likely issue is a damaged surface mount component very near the back side of the board where the + battery lead bolts to the board. This has been identified as a location where we want to move these parts farther from risk of damage but it is likely that the large power ‘ring connector’ has rotated a ways and ripped off or shorted one of the resistors used to sense motor power.

So look at the backside of your MCB board in the broken unit and verify if either of the two closest resistors to the back of P602 were broken off when the large red battery power connector was attached OR that connector has rotated around to rub off those parts.

Specifically it would be R601 and/or R602 but ANY broken components may be involved in this area.

I attach pic from back of board
BrokenSmtComponentsLeadToNoMotorControl

Hi Mark,

Thank you for the detailed response.

Here is what I checked today:

  1. Definitely no power getting to the motors, due to no resistance OR the motor_power_active always reporting FALSE.
  2. I did a ‘tail -f /home/ubuntu/.ros/log/latest/rosout.log’: It’s clean - not too much being written here.
  3. We are using a RPi4 - Same board on all of our units, so I don’t believe it is an issue here.
  4. Interestingly enough - the RED 24VAC cable, was running very close (180 degrees from the cable in the image above) to the P601 and P602 resistors. I couldn’t tell if they were touching. I then removed this RED cable. The resistors were still in place and didn’t look damaged, but perhaps they were short circuited knowing how close this cable could have been.

Kris

Hi Kris,
It is highly likely it is those parts or the rotation of the cable touching a ‘not so good’ point in the circuit.
What I did is simply fake this failure by shorting the point where those 2 resistors join as that goes to the processor. I did this yesterday and proved that if I faked the 24V failure in this way even though there really was motor power it does not matter, the code assumes no motor power and will not do the proper things to drive the motors. This is really a safety feature by the way and is part of ESTOP and is very important to make the code act like it is doing which assumes the hardware is intact where it is not in this case.

Please contact us at support@ubiquityrobotics.com and we will take it from there.
In subject line please say ATTENTION Mark

Thanks, Mark

Thanks Mark.

Email sent to support.