Navio2 Poshold / althold vs Pixhawk & Pixhawk 2.1 Cube

[DrPop (Jedidiah Smith)]

Over the past two years, I’ve successfully built several quads and hexacopters with Pixhawk and clone flight controllers. I love the idea of having ROS available on the drone itself for future robotics projects, so the Navio2 seemed like a perfect fit for my future builds.

After a week of building, tearing down and rebuilding with every combination of flight controllers, three types of ESCs, different motors and frames, I’m left a little puzzled at the Navio2 and its seemingly erratic aircraft stability compared to even a first generation 3DR Pixhawk. I have purchased two full Navio2 setups; one is running on a Raspberry Pi 3 B+ and the other on a Pi 3 A+. Both fly the same:

In Position Hold, Loiter, or Altitude hold, the best result by far is the Pixhawk 2.1 Cube (black) with the Here GPS. As it should be - its price is well above the other two options. You lift off a quad, hex or Y6, and just hover perfectly in place.

A regular “first generation” 3DR Pixhawk with its older GPS and sensors performs slightly less well, and there is a little wander, but fairly acceptable across frame types.

Unfortunately for me, the Navio2 comes in decidedly last in stability and ability to hover without stick input in position hold; both altitude fluctuation and wander are rather severe. I admit I wasn’t expecting this. I’ve tried both Navio2 boards, three different Raspberry Pi boards, both GPS antennas, and all three different frame types, with several different ESC combinations. All produce this same result.

My question to the group at this point is, are the IMU sensors and/or GPS/compass utilized in the Navio2 just that much less accurate, and would I be wasting my time to try to fine-tune things from here to match or beat the Pixhawk? Or are many of you getting Pixhawk (or better) stability out of these boards? If so, I will try to figure out where the issue(s) are with my Navio2 builds.

I honestly do like the idea behind the Navio2 & RPi board combo, and am willing to put some time into tinkering with settings to make things work. But if the end result isn’t going to match or beat even a first gen Pixhawk, I’d appreciate knowing now so that I can change my plans going forward for these builds.
Thank you all for any thoughts on this.

[mlebret (Marc Lebret)]

@DrPop

Or are many of you getting Pixhawk (or better) stability out of these boards? If so, I will try to figure out where the issue(s) are with my Navio2 builds.

Without any log, no way to help you.

There are some points to check:

• vibration levels,
• compass calibration,
• GPS health (antenna placement, settings, hdop…)
• …

Can you share some .bin logs showing your problem.

[DrPop (Jedidiah Smith)]

Hi Marc, thanks for the offer to help! By the way, I have appreciated reading some of your posts, especially the instructions on upgrading to the latest arducopter version. I should reiterate that every build I made this week worked perfect with the Pixhawk 2.1 (cube); nearly as good with the original Pixhawk; but unfortunately not as well with the Navio2. So all the other components I’ve been swapping in and out trying to improve the Navio setup are good. I’m left wondering if there’s some kind of RF issue going on or something that only the Navio is susceptible to, that the Pixhawks aren’t. Or perhaps the Raspberry Pi boards are creating some kind of interference with my setup.

Here’s a .bin file from my last flight tonight. I kept it short and tested for stability in Position Hold, then hit RTL which performed flawlessly. It is by FAR the best flight I’ve gotten with the Navio2 on my CarbonCore Y6 frame. I made three changes since my last Navio flight.

1. Switched to a Raspberry Pi 4 B, in case the Raspberry Pi 3 boards were a problem. Also mounted the case with only strips of double sided tape direct to the deck in case the vibration mount was moving too much.
2. Moved the Flight Controller forward on the drone deck, as opposed to in the middle where I had it before. My thinking here was getting it further away from the RC receiver.
3. Mounted the GPS on an extra extension pole above its normal mount to get it further away from everything else, just in case that was an issue. (Although it gives no issue in the normal location with either Pixhawk GPS.)

This resulted in the best flight I’ve had from all the Navio2 setups I’ve tried. Altitude was fairly consistent for once, and while it did wander and pitch in the air a bit, not having to constantly adjust the throttle was much closer to flying a Pixhawk than previous flights.

Looking at the auto analysis of this log in Mission Planner shows compass issues (I did calibrate them before flight) and motor balance issues - not sure what is causing that, but it’s been on every Navio2 flight I’ve had, with three different kinds of ESCs. The ESCs in tonight’s flight were new BLheli_S ESCs if it matters. I also used two brands of BLheli_32 ESCs in past flights and all perform perfectly in both OneShot and DShot modes on the Pixhawks, but poorly on the Navio2. Any idea on what to change there would be appreciated!
Thanks for the help, and please let me know if you want me to experiment with anything else to try and figure out if we can get the Navio2 to work as well or better than the Pixhawks.
Jed
2020-02-02 22-34-09.bin (1.4 MB)

[mlebret (Marc Lebret)]

@DrPop

Here’s a .bin file from my last flight tonight. I kept it short and tested for stability in Position Hold, then hit RTL which performed flawlessly. It is by FAR the best flight I’ve gotten with the Navio2 on my CarbonCore Y6 frame. I made three changes since my last Navio flight.

Hello,

I had a look at your log.

GPS health is good, i do not think it is necessary to have your antenna over elevated. (Compare the number of sat received with an old log with the antenna on the canopy). I had some bad GPS health with a loose plug (I think it was the cause, as I managed to reproduce it on the bench). Corrective action was to unplug and slightly open the leaves of the antenna plug.

Log show some EKF YAW RESET with compass swap. You could check the compass calibration screen and uncheck use the second compass if needed? Only use the one with the smaller offset.

Your Tilt and Roll P term is quite low, there is a lag between desired and real roll or pitch. It could explain some tendency to float around position.

Oneshot is not working since 3.6.0 (Oneshot 125 for my use). I cannot comment around DShot, as I did not try (ESC not DShot compatible) and have no way to check the output signal on Navio motor out.

[DrPop (Jedidiah Smith)]

Thanks for taking a look! Before I saw your reply this morning, I had switched the Navio2 & Raspberry Pi 4 flight controller over to a smaller quad in case the large Y6 frame was too hard for it to control without really tweaking the PIDs.
This quad is about 560mm motor to motor diagonal size. Sunnysky 2212 motors w/ 11" CF props, 3S battery.

The good news is this got the best performance from the Navio2 I’ve seen yet. Not quite Pixhawk level in lateral stability (still some wandering) but vast improvement in altitude hold.
I made two changes:

1. Swapped out GPS antenna with the other Navio2 setup (first time I traded GPS antennas between the boards) to see if it would make any difference.
2. Changed ESC mode to Normal instead of Oneshot in Mission Planner.

Looking at the auto analysis in Mission Planner on this latest flight, there are still two errors. Any chance you or anyone reading this could shed some light on them?

1. Test: Compass = FAIL - Large change in mag_field (100.82%)
2. Test: Motor Balance = WARN - Motor channel averages = [1453, 1499, 1378, 1446]
   Average motor output = 1444
   Difference between min and max motor averages = 121

Here is the .bin log file from this morning’s flight on the quad frame and a couple pics of the setup. Not perfect yet, but this is real progress, and getting closer to Pixhawk-like stability. Thank you!
Jed

2020-02-04 09-05-49.bin (2.7 MB)

[tatiana.andreeva]

Hi Jedidiah,

@DrPop

Test: Compass = FAIL - Large change in mag_field (100.82%)

We usually recommend using an additional external compass with Navio2.

@DrPop

Test: Motor Balance = WARN - Motor channel averages = [1453, 1499, 1378, 1446]
Average motor output = 1444
Difference between min and max motor averages = 121

I’d recommend you double-check that the geometric center of the drone coincides with its gravity center.
Also, may I ask you to clarify if there were any issues during the ESCs calibration process?

[DrPop (Jedidiah Smith)]

Hi Tatiana,
Thank you for the reply and suggestions. I didn’t see anything in the setup documents about attaching an external compass, so that’s why I didn’t try it. I have several external GPS units w/ their own compass that I could use to test that - I might even try a Here GPS if I can get the cable to work.
Is there any particular reason the onboard sensors of the Navio2 don’t work that well? Is it RF or magnetic interference from the Raspberry Pi board maybe?

Unfortunately on the ESC issue, the ESCs don’t seem to be the problem. I’ve tried three different brands with BLheli_S and BLheli_32 firmware and with the Navio2, since we can only use “normal” PWM mode in Mission Planner, the motor control is just not as smooth. Is there any possible way we can try to get OneShot125 working or preferably even DShot150? I’m sure there are members of the community that would benefit from those modes working, and we would be happy to help test any beta code, etc, that Emlid needs help with if we can make some progress on that front.

EDIT: I’ll rebuild the frame completely just in case it helps the center of gravity too.
Thank you for the suggestions and I will try adding the second external GPS / Compass and see if that makes a big difference.

[Barry_Bolton]

You really do need to mount the Navio2 on a proper vibration setup. You will get much better results than the 2 sided tape setup

[DrPop (Jedidiah Smith)]

Yes, the earlier pic is from when I was testing that. I’ve tried both with and without the anti-vibration mount setup. I agree it does make enough of a difference in the X,Y, and Z vibration values on both an original 3DR Pixhawk and the Navio2/RPi to be worth the extra height - but I wanted to test it both ways just to be sure.

Unfortunately, even after completely rebuilding the test rig into an X8 octoquad on square tubing this time to be sure every motor is perfectly level and square, the Navio2 fails to perform as desired.
I added an external GPS / compass and tried both allowing Arducopter to select the best by leaving all three compasses available to it, as well as forcing it to use only the 3rd (external) compass. Still getting huge magnetic field variance issues in the log files. I have tried in three locations, including the middle of a large field, so it’s not the location either.

[DrPop (Jedidiah Smith)]

Pics of the complete frame rebuild in case anyone is curious. It goes without saying that I tested it on a first gen 3DR Pixhawk and it performs flawlessly. Oh well.

EDIT: Log file of last flight just in case anyone wanted to check it.
2020-02-29 13-43-50.bin (627.6 KB)

[DrPop (Jedidiah Smith)]

Does anyone have any suggestions for anything I haven’t tried yet? Clearly it’s some kind of magnetic or RF interference problem that isn’t allowing the Navio2 based FC to maintain its position in 3D space. Does anyone shield any part of their Raspberry Pi?

The only thing I can think of that I haven’t tried yet is swapping out the RC receiver. I suppose it could be faulty or producing large amounts of RF, etc. I never considered it as a potential problem source before, because it works just fine with both Pixhawk 1 and Pixhawk 2.1 cube. I will try with a completely different brand and model of RC receiver on Thursday when I get a chance, just in case.
I’m happy to entertain any other suggestions at this point as well.
Thank you.

[tatiana.andreeva]

Hi Jedidiah,

@DrPop

Is there any particular reason the onboard sensors of the Navio2 don’t work that well? Is it RF or magnetic interference from the Raspberry Pi board maybe?

Navio2 built-in compass is located directly on the board. Usually, the external compasses that are placed remotely work much better.

@DrPop

Is there any possible way we can try to get OneShot125 working or preferably even DShot150?

We’re now looking into the possibility to implement OneShot125 support. I’ll inform you once we have any news on this question.

We’re now checking your log file. I’ll write back when we conclude anything.

[DrPop (Jedidiah Smith)]

Thank you! If we can’t get Oneshot125 working for any reason, then even regular Oneshot is about 8 times faster than “normal” PWM mode, so that would be a big step in the right direction.
I’m willing to be a beta tester for any code changes you might need to test for getting Oneshot or Oneshot125 to work at this point as well.

[mikhail.goryachev]

Hi Jedidiah,

We’ve looked through your log and have several guesses on how the stability can be improved.

Could you, please, conduct an additional flight during calm weather or even indoors, if it is possible, and send us logs? It’ll provide us clear data on what’ going on with hardware’s input/output.

Also, it seems, that your last assembly uses different sets of propellers (carbon and solid-plastic for one axis). Not sure if they have fully equal mass. Thus we’d recommend installing equal screws and carrying out some more tests with the new setup.

Furthermore, we advise adding ground plane (any piece of conducting material will be good) to the planar antenna to enhance signal reception and ensure, there’s as little EM disturbance as possible.

[DrPop (Jedidiah Smith)]

Hi Mikhail, thank you for checking this out. Yes, the bottom props are pitched higher than the top props for improved efficiency in a coaxial setup. This flies perfectly with a Pixhawk running Arducopter, but I will remove the bottom motors and props, and make it a regular quadcopter again for the next test flight to make it easier for you to diagnose any problems.

I will wait for perfect weather, fly again when I get a ground plane made for the antenna, and upload the log file.
Thank you.

[Barry_Bolton]

Tatiana, with respwct, Emlid should not be looking into the possibility of implenting dshot, you just impliment it

[Barry_Bolton]

But then again. Is dshot not automatically implemented with the arducopter firmware

[DrPop (Jedidiah Smith)]

DShot would be awesome because of the ESC telemetry data BLHeli_32 offers. However, DShot support and BLHeli passthrough was only fully implemented in Ardupilot within the last year.
So that might be pushing it a little too far at the moment. As much as I would love DShot support, if we could just get OneShot and/or OneShot125 working again, that would be a big step in the right direction.

As @mlebret has pointed out in several posts, OneShot was working on Navio2 at some point before Arudcopter 3.5, but has been “broken” ever since. You can select OneShot mode from the ESC menu, but currently it doesn’t change the output. It acts just like “normal” PWM mode.

[DrPop (Jedidiah Smith)]

@mikhail.goryachev - finally had time and good weather to give this another try. Flew it as a quadcopter this time to make it easier to diagnose the log files. Even replaced the RC receiver with a new FrSky X8R just in case the other receiver was causing some strange RF issue.
It flies just fine - take off, landing, all flight is as expected. However, it just can’t seem to hover in place well enough for what I’m used to with the Pixhawk flight controllers. For some reason the quadcopter wanders too much in Position Hold mode, and still returns this error with auto analysis of the log file:
Test: Compass = FAIL - Large change in mag_field (202.31%) Max mag field length (1378.48) > recommended (550.00)

That is the best result, using an external GPS/magnetometer unit that I use together with good results on a Pixhawk. If I allow Arducopter to use the on board compass of the Navio2, the results are worse. So the advice to use an external compass is good; just not good enough for what I’d like to see.

Here’s the log file if it helps, but I’m just not sure there’s anything else I can even change to make any more differences at this point. Thanks for your interest in helping.
Jed

2020-03-15 19-05-53.bin (5.7 MB)

[mikhail.goryachev]

Hi Jeddiah,

Thanks for setting the test. I’ll look into your logs and let you know if I find something that can help us in debugging.