Both Blue and Red S/W is on but motors don’t work. 2 weeks ago worked well but now doesn’t. The symptom is an excitation of the motors is very weak and don’t work even we publish cmd_vel as same as a situation Red button is off.
We checked some point …
raspberry pi works correctly and publishing node correctly.
5 blue LEDs on the main board lit correctly.
software installed is the latest version.
battery is fully charged according to the topic battery_state. It shows over 90%, about 27V.
batteries spec we tried are 12[V]5[Ah] x 2 and 12[V]9[Ah] x 2, both are SLA.
Powers from the top of the main board supply 5 and 12 volt correctly.
The suspicious factors are …
Circuit for motor control is broken.
Batteries don’t supply much power.
Very good - thank you for your diligent checking of the robot. A couple of questions.
If you turn on the robot do the motors hold in place? If you try to move them with your hand they should remain fixed and resist your movement. The motors have active systems that hold them in place that operate even if the raspberry pi is not operating.
Do you have the CR2032 battery installed. This is a small button battery that is installed on the back side of the board and runs the real time clock. If the real time clock is not functioning it can cause some parts of the software to crash and the motors might not operate.
Sorry for hijacking the thread. I want to add some comments on the issues I faced recently with the motors which are more or less similar to the issue in this thread.
I acknowledge @davecrawley point on backing the RTC power with the CR2032 battery. We too faced the issue of not having proper time.
The magni_base service is started at boot time. Due to some issues if the internet is down during that time. The NTP could not be able to pick the correct time, and it uses the time which kernel will pick from the RTC (which is the RTC reset time) and the ros nodes uses that, once the NTP corrects the time when internet is available due to the big difference in the time (reset time vs actual time), the ROS node might fail. We solved it by backing the RTC clock with battery.
Yes that’s right - we put the real time clock in every Magni because:
The raspberry pi doesn’t have a real time clock
Its a known issue with ROS in general that if the time is not accurate things will either misbehave or crash - particularly if you are sharing topics between ROS master on the robot and another computer.
The only way to guarantee that time will be accurate at boot time (when many services start to come up) is to have a real time clock.
So put the CR2032 battery in - otherwise you can have unexpected behavior.
1.If you turn on the robot do the motors hold in place? If you try to move them with your hand they should remain fixed and resist your movement. The motors have active systems that hold them in place that operate even if the raspberry pi is not operating.
The robot doesn’t hold in place. When I push the tires with my hand, I feel “a little” resist that is not enough to hold in place.
2.Do you have the CR2032 battery installed. This is a small button battery that is installed on the back side of the board and runs the real time clock. If the real time clock is not functioning it can cause some parts of the software to crash and the motors might not operate.
The battery is not installed, but also another Magni works well without this battery.
I found an error “left(right) PWM limit reached” on my rosout.log. I have already sent you the log file. Did you find something on that?
Hello, I am a UR hardware engineer. Sorry to hear of the issue, maybe I can help.
If you have available a voltmeter and feel up to taking a measurement or two that may help.
I will reply as if you do have a voltmeter just in case.
You have reported the blue leds and the battery state AND the 5V main and 12V main supply so that is good so far. When you say you have 12V and 5V the ones that matter are the ‘Main’ supplies for this so that is on the left 4-pin white connector (that looks like typical PC disk drive power connector). I will assume you did that but mention just in case.
Since you seem to have a voltmeter and steady hands we will see if the motor power protection circuit is tripped or if it is just not supplying the main motor power (We are putting more LEDs on the board for the current production run by the way to avoid some of this in future by the way)
As you look at the front of the robot and can see the board the bottom left large lug nut OR the negative terminal of your battery going to the black wire will be the ground or negative or black line of you voltmeter. We want to see if the large ‘tab’ that is on the power MosFet that is in the lower right far corner has 24volts or so on it or not. If it does NOT have 24V that is our problem and we go from there.
If above is 24V or so then we measure the top left thick pin of the same power mosfet which is the power AFTER it gets through a complicated power safety circuit that senses battery conditions and over-current and so on. Because this is 24V at very high current please be very steady and don’t let the voltmeter slip off and short this to ground. Take your time and be steady. Ideally one person holds the lead and another person reads the voltmeter OR use a probe that has a pin at the end to hold it steady on the lead.
I have added a picture to add clarity to this check
Hello Mark,
What could be the reason for not having the 24V on the source of the MOSFET ? Yesterday one magni is down, motors are not responsive. I followed your suggestions, to check the voltages on the MOSFET mentioned in your post. The source has 0V and the drain has 27.6V.
Also there are some error logs: “left/right PWM limit reached”
In looking at issues seen up to and including the Rev 4.9 controller boards we have identified and addressed in our now in production verstion 5.0 board two things that are designed to solve the issues seen on some field units where motor power is lost.
(There is another issue related to not having a battery in the back of the board that leads to motors stopping but in that case there WOULD still be 24V so I restrict the discussion to just the hardware loss of 24V)
The ‘short’ answer is we are aggressively addressing and fixing this issue in our rev 5.0 boards now in production. It is not easy to fix this on rev 4.9 boards in the field but we here can fix it if required and it is arranged.
Here is the ‘long answer’
The main issue is that through a mistake in parts procurement and us not catching it the chip that does power protection for battery low, battery high or overcurrent (short protection) ‘latches’ and once triggered it remains totally off until a full power cycle. A second issue is that the current sense was set too low so that if the motors are made to jerk in a very strong way it would trigger the protection circuit.
So our fix is to use a motor protection circuit that once triggered will after a fraction of a second re-try and keep doing that till the fault is removed. This then allows an accidental short or a strong surge in the motor current to NOT keep the motor power off.
We also have put in an LED that if the motor power gets cut off for whatever reason it will turn off. We also are adding other logic so the high level Linux based code can know if motor power has been lost either from the red switch being off or any other reason.
In the case of returned rev 4.9 boards we can replace a part to avoid the power staying off but it is a very fine pitch part and should not be tried to be fixed without experienced surface mount soldering technician help with proper gear (very tricky work).
