NAVIO2 RPi 3 Reboots when moving control surfaces

Hi everyone,

I am using the NAVIO2 on the Raspberry Pi 3 Model B.
I am using the Raspbian Stretch image from EMLID and ArduPlane 3.8

Issue Description

The NAVIO2 and Raspberry Pi reboot when control surfaces are moved too much or too frequently.

Setup

I have 2 standard metal gear digital servos attached to each aileron/flap and two micro metal gear analog servos attached to the two Vtails. Also I have a 1100KV brushless motor (but the motor is not connected to the ESC for the purposes of this issue).

I am using a 2S 25 C Lipo capable of 12800 mAh.

I am also using the EMLID power module (There are separate issues with the power module where it is not able to display current or battery percentage. It displays the voltage that too almost 1V less than what the multimeter shows me).

I am using a 65 A ESC (4A 5.2V UBEC).

Lastly, I do not have a Tx/Rx controller therefore I am using WiFi for setup and then Joystick over WiFi to test the control surfaces.

In addition I have the RFD900u modems for telemetry and flight control.

Steps to create the issue

I have plugged in the left aileron on servo 1, right aileron on servo 5, left and right vtails on servos 2 and 4 respectively and throttle and BEC input on servo output 3.

I have disabled Arduplane to start automatically on boot to enable me to know when the NAVIO2 reboots.

On entering sudo ardupilot -A udp:192.168.1.x:14550 I am presented with the following screen.
ardupilot startup terminal output

Then if I go over to Mission Planner and connect over UDP, everything starts up.

I switch to manual mode and enable joystick (connected to my GCS PC over USB).

If I move the control surfaces, then I am able to see the control surfaces responding accordingly without issues initially. However after an inconsistent amount of time while moving the joystick, the autopilot reboots and I get the following message on my terminal (see screenshot) telling me that the SSH connection has been lost.

terminal connection drop

I have tested this over the RFD900u modems as well and I have experienced the same issue there as well.

The reason I believe that this may be a power related issue is because, when I have the Raspberry Pi’s official power supply connected I have not been able to see replicate this issue. However when the power is through the NAVIO2 board’s power port or through the Servo Rail I can see this issue happening.

The battery is new this is its first discharge cycle. Mutlimeter reading says that the battery is at 7.8V.
The power port on the NAVIO2 read 5.32V.
The ESC/BEC’s connection to the servo rail reads a potential difference of 5.42V between its red and brown wires.

My obvious issue here is that until I can get the reboot issue sorted I won’t be able to fly and secondly I can’t seem to predict when it’ll happen after I’ve met the necessary set up prerequisites to force the issue to happen.

Therefore if you could provide any help then it would be of great help to me.

Thanks
JD

1 Like

Thanks, JD for your extremely detailed and well-written issue report. We’ll look into it beginning of the next week.

Anyway, could you please send us a pic how everything’s set up and hooked up?

Hello George,

Setup Photos

As requested please find photos of the set up below. One photo is of the overall setup, the second shows the attachment of the micro servos in the left and right vtails.


Additional standalone ESC+Motor+Battery Testing

So today, I went to a hobby shop and guys there helped check the ESC calibration. They hooked up the ESC with a spectrum Tx/Rx and ran the motor at high speed for about a minute. The ESC seemed to have been calibrated and there were no drop or irregularity in the power supplied.
The BEC output is 5.42V

Additional Power Tests on NAVIO2+RPi3

Scenario 1 - BEC not connected to servo rail. Raspberry Pi powered with Raspberry Pi power cable.
Result Unable to recreate issue. Potential difference across the DF13 power port of NAVIO2 is 5.34V.

Scenario 2 - BEC is connected to servo rail. Raspberry Pi powered with Raspberry Pi power cable and DF13 connector from power module is connected to power port of NAVIO2.
Result Unable to recreate issue. The NAVIO and RPi3 doesn’t reboot. However, on running sudo emlidtool ardupilot the following result is seen (with warnings of board voltage). Potential difference across the DF13 power port of NAVIO2 is 5.34V

Scenario 3 - Same as scenario 2 but this time Raspberry Pi is not powered by Raspberry Pi power cable. DF13 power connector to NAVIO2 and BEC connected to Servo rail.
Result Able to recreate issue. The NAVIO and RPi3 reboot shortly after when moving the joystick.

General Summary of tests

From the tests above it seems like now I can recreate the issue. It happens when the NAVIO2 and the RPi3 is not being powered by the RPi3 power plug. Definitely looking like a power issue.

Please let me know if there is anything that I am missing.

Thanks again
JD

Hi,

I also saw a similar problem with my setup.

I have two large 90W motors powered directly from lithium batteries.
The navio2 is also powered from the batteries via the Ri Pi power module

https://emlid.com/shop/power-module/

When I energise the motor (e.g when when coming out of estop) I would sometimes notice that the RPi 3 would restart. At this stage I haven’t had the time to debug it but I would assume the inrush current caused by the motor causes the voltage level to dip in the power module which causes the RPi to restart.

My guess is that there isn’t enough power filtering done on the power module to deal with inrush current.

Hello @george.staroselskiy, were you guys able to have a look into this issue a bit more to see if there can be a resolution on this?

There seems to be two issues

  1. The inrush current causes the current to the board (from the power module) to drop
  2. The board voltage seems to be a bit high (based on the warnings at the start of ardupilot).

Thanks
JD

The BEC provides 5.42V, while the power module outputs 5.25V. The ideal diode OR chooses the source with higher voltage, so RPI is actually getting power from the BEC. Once you start moving the servos servo rail voltage becomes unstable and RPi reboots. My suggestion would be to choose a BEC with lower voltage or to unsolder R53 resistor thus completely disconnecting the servo rail from the internal power circuitry.

Hi @igor.vereninov, thank you for your comment.

However, please see the following reasons why I believe that this is perhaps more to do with the Emlid Power Module not being able to supply steady current.

  1. It states that the power module and the servo rail serve as redundancies for each other. So therefore, if the servo rail was to get unstable then, according to the docs on the Emlid site, the board should automatically switch to the power module for power.

  2. The BEC voltage is constant on 5.4V and when I ran the motor test (which draws at much higher current than the servos) at the hobby shop there were no drop outs in power and the motor was able to perform smoothly.

  3. Most importantly - In addition to the servo rail and the power module, I connected an old phone backup battery (5V, 1.5 A, 1600mAh) via USB to the Rpi3. This eliminated the reboot issue. My question is - if it always picks up the higher voltage (in this case from the BEC), then the issue should have persisted and the Rpi/NAVIO2 should have rebooted as soon as I moved my servos. But here on running the servos and the motor the Pi/NAVIO2 does not reboot.

Hence, I think, that this points more strongly to the fact that the power module is probably not able to power the NAVIO2/Rpi because when I add power directly through to the Pi, it is able to perform just fine and does not reboot (even though the BEC still provides higher voltage on the servo rail).

Therefore can you please test the Emlid power module. In any case, it is not showing accurate voltage reading and current reading is always 0A and battery is always at 100% or 99%.

Thanks
JD

Regarding point 2, the motor does not draw its current from the BEC, so it would only affect BEC voltage, if the motor current would let the lipo voltage drop under the minimum input voltage of the BEC.
Servos can draw quite a lot of current and also create noise on the power cables.
Two things I would try to get everything working is to put a capacitor on a connector of the servo rail between plus and minus.
The other thing is to remove the plus wires from the servo connectors and connect them to the BEC seperatly, connecting only signal and ground from each servo to the servorail.

Hi @schuermannsebastian, thank you for the suggestion. I understand your point about the motor not drawing current from the BEC. In my scenario the motor does not need to be connected for the reboot to happen.

Secondly, even if the servo rail voltage drops then according to the docs the module should automatically route power through the power module. It seems like this is not happening.

Moreover, the issue can be fixed (although this is a band-aid solution) if I add a power supply directly to the raspberry pi, in addition to the power module LiPo. This clearly shows that the power module is not able to regulate power to the NAVIO2 board.

Lastly, the power module is not showing any current values for the LiPo, the voltage shown is incorrect and battery percentage is always 100%. There is definitely something amiss in the Power Module.

Hence would be great if the Emlid guys can shed some light on this…

You have to calibrate the powermodule in Missionplanner for both voltage and current to have them displayed correctly.
The settings should be pixhawk, voltage and current and other.

Before I started using the power module, I had already configured the power module in mission planner using those values. Still I get no measured current, always 100% battery and erroneous voltage reading. All the more reason to think that something’s not quite right in the power module.

Hi @JDAS,

Servos can generate large spikes in voltage, not just drops. The power supply redundancy protects from power supply dying or a loose cable when one of the power inputs stops providing power. It is an analog circuit, so it has limited ways to determine if the input is good or bad. I believe that if you unsolder R53 and completely disconnect servo rail from power circuitry you will no longer see this issue.

Hi @igor.vereninov,

Okay I’m not able to understand why then I don’t see the issue when I have a 5V, 1.5A battery directly to the R Pi? If the movement of the servos cause voltage spikes then this too should reboot the system, right?
Also why the power module is not able to show me accurate voltage, current and battery percentage data even though mission planner is configured correctly to use the power module.
I’m a little worried to unsoldier R53 because then I lose the redundant power supply capability that you guys built (and I’m not too good at unsoldering). Plus since all servos cause spikes have you guys seen this issue with other users or during your testing?
Thanks

Hi @george.staroselskiy and @igor.vereninov,

Can I please get you to provide some guidance on my queries regarding the inconsistencies in the power module’s behaviour? Also why I see no reboots when I add another power source directly to the RPi (without removing the servo rail from the board circuitry). There’s definitely something not quite right here.

Thanks,
JD

hi
it seems like you power rfd900u from navio - you should power rfd900u directly from a 5V BEC;
you could try to solder a (few) capacitor(s) 470uF or higher to 5V and GND on the servo rail (or solder it to a very short cable and connect to the servo rail); it could help with voltage drops and spikes;

Hi @panky, I had considered the same thing and therefore disconnected the RFD900u. And even with it disconnected I was able to recreate the reboot issue.

BTW - I have been in touch with RF Design and they have said that since the RFD900u is not as powerful as the 900x therefore it doesn’t need a separate power source.

Also it is similar to the 3dr radios and is 100mW.

But regardless the reboot happens when the NAVIO2 module is connected over Wi-Fi only and the radio is physically disconnected.

Thanks,
JD

your issues seem to be related to your servo and you need to take care of the voltage spikes/drops; even if you manage to prevent navio from rebooting - you will take the risk of a malfunction or damage of other electronics connected to the servo rail; so either caps or a BEC capeable of enough current for the servo(s) should solve your problems;

Good Point @panky.

I’ll try to see if I can swap out my standard servos and recreate the issue with other servos.

In the meanwhile any idea why the power module isn’t showing the current voltage/current data?

Thanks for your inputs. I’m anxious about the servo rail spikes/dips. My BEC is rated for 4A current. I wouldn’t think servos would pull more, would they?

Thanks

Would you like to try something like this https://hobbyking.com/en_us/turnigy-min-power-distributor-ubec-red.html?___store=en_us

A PDB may help you.

Thanks @dsmoura.

As a last resort I probably would have to try something like that. I am at a stage where additional weight would be a problem for my plane. But before that I’ll try to recreate the issue with different servos.

To avoid having to do all this I went for the standard power module from Emlid. Unfortunately, I am not able to get it to give me correct readings for voltage and current. Moreover the very fact that the Navio2 / RPi doesn’t reboot when power is directly supplied to the Pi makes me think that voltage spikes from the servo rail are probably not the (only) issue causing the reboots. Else the reboots would have happened regardless of the direct power supply to the RPi. There must be something to do with the power module. My servos are standard metal gear digital servos. They give out 13kg.cm torque.

I’m hoping the Emlid is able to revert back to me on this.

Also agreeing with @panky I’m anxious that the servo rail voltage irregularity may affect the board. Which is why I’ve suspended testing with my current setup until I’m sure that my board will be safe.