Introducing Navio2

Originally published at:

Hello friends,

We are happy to announce Navio2 - the new version of Navio autopilot.

We have listened closely to our community and included numerous improvements in Navio2.


New features in Navio2


Dual IMU. We’ve added second IMU chip to improve flight experience and for redundancy.


Advanced power circuitry. Triple ideal diode or-ing scheme was already present on Navio+, Navio2 also features overvoltage and overcurrent protection circuitry on the power module port to protect both the board and your Raspberry Pi.


Improved MS5611 performance. Transactions from other chips on the bus, which MS5611 is connected to, can produce noise during the conversion. We left MS5611 the only sensor on the I2C bus to overcome this.


PCA9685 PWM generator replaced with a microcontroller. On previous Navio version PWM generation was handled by PCA9685 chip. Main limitation of this chip is the inability to control frequencies for separate channels. This lead to problems with motors and servos that work on different frequencies. To eliminate that problem we used a microcontroller that allows to set frequencies for output channels by groups.


PPM\SBUS decoding done by microcontroller instead of DMA. On Navio+ we used DMA to sample PPM signal which was quite heavy on system resources. On Navio2 a microcontroller handles PPM\SBUS sampling leaving processor cores of Raspberry Pi 2 for your tasks.


AUX SPI. Navio2 is the first HAT to utilize AUX SPI controller on Raspberry Pi. Using two SPI controllers allows us to distribute sensors more efficiently. Having twice the bandwidth of other Raspberry Pi based solutions, we are managing to move more data at a greater speed.


ADC port. Using additional ADC channels on Navio+ was not user friendly due to ADC channels being only available on pads at the bottom of the board. On Navio2 these channels are easily accessible on a DF13 port.


Better Linux integration. PWM, ADC, SBUS and PPM are integrated in Linux sysfs allowing for easy access from any programming language. Even deeper integration is coming in the future.

Other small changes

  • Right angle servo header
  • RGB LED position in the board center for better LED visibility
  • Pulled up pins in UART port to allow easy 3DR Radio connection
  • Nylon screws in the package to avoid magnetic interference
  • Camera cable cutout
  • PWM channels are protected by ESD clamps
All these new features come at the same price and Navio2 is also available with edu discount.

You can find more information and order Navio2 here.


Best regards,
Emlid team



I literally had my navio+ delivered Friday, haven’t even had a chance to play with it yet. Would have waited for this :frowning:

1 Like

Great news guys. Cant wait…

1 Like

Very nice to see that you continue the development of your awesome NAVIO system. Just in time for my next quad! :slight_smile:

Is the lower CPU load significant and will it enable better video streaming while running APM?

1 Like

Well done, specifically with the RC input co-processor and improved HAT spec (slot for camera ribbon cable).


David, Navio2 is shipping in mid January so there is plenty of time to get to know Navio+. If you decide to upgrade, we will be happy to provide you a discount for Navio2, just send us an email :wink:

Thanks Ole! It definitely should, we have completely eliminated DMA load, which affects camera performance.

1 Like

Great progression.
Beside to this, I like the 90° tilted pin connector :slight_smile:

1 Like

Is it still required to cover the new high resolution barometer with a sponge/foam?

looks amazing, congratulations.

Redundancies, increased processing, improved form factor, nice work!

I look forward to seeing what this little beast can handle :smiley:

Looks like you payed attention to the comments and input from the community, that’s always nice to see.

Keep up the good work guys!

Will the Navio2 be able to run APM in auto mode and Rtklib simultaneously? Using the onboard GNSS module.

1 Like

Thanks for kind words guys!

@Al_B The barometer is the same - MS5611, so it still should be covered. We’ve just improved its performance a little bit by eliminating other transactions on the bus.

@matthewbrooks Unfortunately M8N is too limited for this (as well as interfacing capabilities of RPi), so we are not working in this direction.

My Navio+ is still in transit with the courier. I should receive it early next week. :confused:

I hope a discount for upgrading on Navio2 will apply to all of us. :no_mouth:

BTW, why there is a new wire pack for Navio2 with different connectors?

If your Navio+ order is recent we will give you a discount for Navio2.

Navio2 has 2 x 6-pin connectors and 1 x 4-pin. Navio+ has 4-pin, 6-pin, 7-pin.

Here at Airborne Projects when we manage to test NAVIO 2 we will also design a new OpenSource case to it similar to the Navio+.

1 Like

TRK-MEAS and TRK-SFRBX messages have been used for RTK on Navio+.
I thought the issue was the IMU and GPS buth using the SPI ( the link below) and the new aux SPI controller would fix it.

Is there another hardware issue or is it some software problem that the community could work on?

Or, there might be enough demand from APM UAVs wanting an all in one RTK flight controller to offer a Navio2 with a M8T?

IMU and GPS are still one the same bus, so the problem still exists.
TRK messages are limited compared to RAW and not all M8N chips provide them (and those that do don’t do that officially), so we can’t rely on them as a manufacturer of a product.

Great development! Could you elaborate on the reasons for the dual IMU?
With regards to static redundancy, wouldn’t you need (at least) three IMUs to tell which one is feeding “bad” info?
And with regards to performance, are both IMUs used during normal operation? Does this actually increase performance noticeably? Are they set to different ranges?

As a Navio+ user with great interest in sensors and navigation I’m really interested in these topics. Keep it up!

@eirikwor It makes sense to use two inertials because gyrometers are drifting (always). One can average the gyrometer readings, and thus reduce the drift estimate. Of course the accelerometer is used as reference for correcting the drift as well, but it is not bad to average the gyros.
If one sensor fails, this will be detected as well, because the readings become odd. For this no third sensor is necessary in most cases.

@dgrat Thank you for the answer! Gyroscopes do not drift, but they have a (time varying and temperature dependent) bias on their measurements, in addition to (colored, but often assumed white) noise. To obtain an attitude estimate from gyro measurements integration is required, and it is this integration of white noise and bias that lead to drift in the estimate. As you point out this is countered by assuming negligible linear acceleration with respect to the acceleration from gravity, giving a rough estimate of the downwards direction.

An additional gyroscope would give you two measurements at any discrete time and, assuming white noise on those measurements, the standard deviation of their average works out to be 1/sqrt(2) times, or 70% of, the standard deviation of the separate measurements (assuming equal amount of noise). This is only marginally better, and heavy corrections from the accelerometer is still needed. The same holds for the initial bias (assuming it is normally distributed), meaning one could only expect to get rid of about 30% of the bias when using dual IMU. A gyro and accelerometer fusion algorithm should already be able to get rid of a lot more than that by integral action, rendering the 30% improvement rather unnecessary.

As for the static redundancy, a dead chip is of course easy to recognize, but in general one needs more to actually say which measurement is bad. What do you do if the two IMUs disagree, but both could be valid data? You need three or more to tell the bad from the good, but two is sufficient to tell the obviously bad from the good. And is sudden IMU death a real potential problem? (I have absolute no idea)

I might very well be wrong on a number of things, so feel free to arrest me. This is also not intended as criticism towards the new Navio in any way. The designers obviously know what they are doing, and there’s probably a good reason to put two IMUs on there. I just don’t know it.

1 Like