Raspbian Buster with Raspberry Pi 4 support for Navio

Hello guys!
We wanted to share Raspbian Buster with the long-awaited Raspberry Pi 4 support.
And here’s a list of new features and improvements.

  • ArduPilot project has been updated:
    • ArduCopter: 3.6.11
    • ArduRover: 4.0.0
    • ArduPlane: 4.0.0
    • ArduSub: 3.5.4
  • Linux kernel was updated to 4.19.83
  • Added support for Raspberry PI 4 Model B
  • Rootfs auto-expanding on a first boot
  • Fixed servo rail voltage
  • ROS key was updated

To update you’ll need to flash the new image to SD card.
Here’s the changelog.

Waiting for your feedback!


Thanks for your work.

Buster image on Pi4 and Navio2 is running at home. Configuration with RCIO update is ok.

Arducopter 3.6.11 is running, Oneshot 125 output is not working. Normal PWM is fine.

Well done guys - look forward to trying it out…

Hi folks,
Could you guide us towards integration of navio2 on raspberry pi 4 with Ubuntu arm64…
Raspbian is nice but it uses 32bit architecture… Which is a shame on the rpi4. There is a set of developers that uses navio as it is without arducopter ardupilot or similar software stacks. For example we are currently testing ros2 with Ubuntu arm64 and navio+. We would like to migrate to the fastest raspberry pi 4 keeping arm64 and possibly upgrading to navio2. Could you help us?

You should put out a emergency directive instructing all Navio2 owners to upgrade to the new image in light of I2C strom that can cause various autopilots to spontaniously reboot midflight as in this article


Well the Ardupilot firmware that is used in the Navio2 is 32 bit so they will have to upgrade that.

At this point in time personally I do not see any added benefit of moving from 32 to 64 bit as the current firmware only uses around 6 to 7 % perhaps a little bit more of the raspberry pi’s memory. Might be a little more infact.

But in fact I am not going to get benefits of ardupilot at all.

I am concern that people who bought this piece of electronics cannot use the full potential of the underlying hardware because of lack of support.

Using 64 architecture in general increase the computation capabilities (i.e. speed using 64bit instructions) and reduce time to access memory.

If you don’t see this benefits I completely understand, but your point of view is a normal customer perspective and I respect it. My question comes from an advanced usage perspective, perhaps beyond the regular use people in emlid community are looking for.

I truly believe that emlid, as a tech company, will understand also my perspective and will reply soon or later with their idea addressing (or not) the support for the most advanced usage of their equipment.


Hi Barry,

Thanks for bringing it to our attention! We’ll explore this and get back with any news.

Hi @muawijhe,

Thanks for the suggestion! We don’t have plans on integration Navio2 and RPi 4 with Ubuntu currently, and hardly can be of much help in this question, I’m afraid.

I’d recommend looking into our kernel source code as it might be useful here.

Hi Barry,

This issue hardly can affect Navio2 as, according to the article, it influences STM32 based flight controllers only.

1 Like

A post was split to a new topic: Segmentation Fault on Navio2 last image

What was wrong with the servo rail voltage?

There is still a BIG bug active on Navio and Edge with OneShot125. It came with Arducopter 3.6.0 and is not solved with Arducopter 4.0.

For information, this bug is quite absent on the other Arducopter capable cards.

For large copter users (Low KV motors), OneShot 125 is a way to solve desynchronising. There was also DShot 150, but 3.6 dev shut down the possibility with new BLHeli32 settings if you need more than 6 motors (if Emlid hardware is OK with such configuration?).

This is pretty much why I’m letting go of running the Navio2. After a couple weeks of trying multiple Navio2 FCs, three RPi versions, different ESC and motor combos on both quad and hex builds, I just cannot achieve the same stability or smoothness in flight with the Navio2 that I get with the Pixhawk and Pixhawk 2.1 Cube on the same hardware.
I believe it’s at least partly down to running the ESCs in “normal” PWM mode. Dshot150 is best, but even Oneshot125 is a good step in the right direction, and unfortunately, neither of those seem to work right with the Navio2 as of February 2020.
sigh It was a great idea on paper…

I agree. For me it was endless crashes and unexplained stopages mid flight and the inability for Emlid to give support online that made me stop. It is a brilliant idea on paper like you said

Hi Marc,

I’ve conducted some tests with OneShot125 ESCs, different ESC modes, and versions of ArduCopter.

If I get correctly, OneShot125 mode used to work with ArduCopter 3.5.7. However, I didn’t notice any difference in motors’ performance when changing the PWM_MOT_TYPE parameter in Mission Planner between Normal and OneShot125.

Could you clarify what behavior you expect with OnetShot125 PWM_MOT_TYPE?


With Oneshot125 selected and working, ESC refresh rate is 8 times faster than standard PWM.

If you look at the RC-Out log (mot 1 to 6 in my example), the working range is 125-250 instead of 1000-2000 PWM range. It is the way to know Oneshot125 is activated and working. With a Oneshot125 capable ESC, the ESC detect the Oneshot signal and work accordingly.


As the refresh time is shorter, there are less possibility of ESC-Motor desynchronising, as with PWM and larger low RPM motors.

Oneshot 125 is working with latest arducopter version on my CUAV V5+ but no way to have it working with Navio2 or Edge since 3.6.x version.


1 Like

Hi Marc,

Thank you for the description!

We are working remotely now and, unfortunately, don’t have access to all instruments. We’ll be able to continue the investigation once we get back to the office.

I’ll let you know as soon as there is any news.

A post was merged into an existing topic: The new rpi4 8 gig and Navio Image not working