APM 3.3-rc9 beta testing

I just worked this out from @george.staroselskiy’s extremely useful post here (regarding missing GCLIB 2.15+):

  1. Follow @george.staroselskiy’s instructions to edit the debian sources and switch from wheezy to testing, run apt-get update then install the newer GCLIB. (“sudo nano /etc/apt/sources.list” then change “wheezy” to “testing” in the first line, followed by “sudo apt-get update” and “sudo apt-get install libc6”).
  2. Optional (but you’ll probably do it later anyway) - Run a full upgrade with “sudo apt-get upgrade”, respond to a load of prompts with default answers. According to a warning at the end of the upgrade you should run dpkg to purge unused locales.
  3. Create the script below to help you download and run APM direct from DIY drones latest APM build (the first supporting Navio):


# Navio APM Download and Install Script
# =====================================
cd ~

# Remove Emlid build
sudo dpkg --remove apm

# Download DIY Drones build
# Optional: comment all "wget" download and "ln" link lines for all other APM variants (e.g. when using a quadcopter comment everything except "navio-quad").
sudo rm /opt/apm --recursive --force
sudo mkdir /opt/apm
sudo mkdir /opt/apm/bin
cd /opt/apm/bin
sudo wget http://firmware.diydrones.com/Plane/stable/navio/ArduPlane.elf --output-document=ArduPlane
sudo wget http://firmware.diydrones.com/Copter/stable/navio-heli/ArduCopter.elf --output-document=ArduCopter-heli
sudo wget http://firmware.diydrones.com/Copter/stable/navio-hexa/ArduCopter.elf --output-document=ArduCopter-hexa
sudo wget http://firmware.diydrones.com/Copter/stable/navio-octa-quad/ArduCopter.elf --output-document=ArduCopter-octa
sudo wget http://firmware.diydrones.com/Copter/stable/navio-octa/ArduCopter.elf --output-document=ArduCopter-octa-quad
sudo wget http://firmware.diydrones.com/Copter/stable/navio-quad/ArduCopter.elf --output-document=ArduCopter-quad
sudo wget http://firmware.diydrones.com/Copter/stable/navio-tri/ArduCopter.elf --output-document=ArduCopter-tri
sudo wget http://firmware.diydrones.com/Copter/stable/navio-y6/ArduCopter.elf --output-document=ArduCopter-y6
sudo wget http://firmware.diydrones.com/Rover/stable/navio/APMrover2.elf --output-document=APMrover2
cd ~
sudo chmod +x /opt/apm/bin/*
sudo rm /usr/bin/ArduPlane* --force
sudo rm /usr/bin/ArduCopter* --force
sudo rm /usr/bin/APMrover* --force
sudo ln --symbolic /opt/apm/bin/ArduPlane /usr/bin/ArduPlane
sudo ln --symbolic /opt/apm/bin/ArduCopter-heli /usr/bin/ArduCopter-heli
sudo ln --symbolic /opt/apm/bin/ArduCopter-hexa /usr/bin/ArduCopter-hexa
sudo ln --symbolic /opt/apm/bin/ArduCopter-octa /usr/bin/ArduCopter-octa
sudo ln --symbolic /opt/apm/bin/ArduCopter-octa-quad /usr/bin/ArduCopter-octa-quad
sudo ln --symbolic /opt/apm/bin/ArduCopter-quad /usr/bin/ArduCopter-quad
sudo ln --symbolic /opt/apm/bin/ArduCopter-tri /usr/bin/ArduCopter-tri
sudo ln --symbolic /opt/apm/bin/ArduCopter-y6 /usr/bin/ArduCopter-y6
sudo ln --symbolic /opt/apm/bin/APMrover2 /usr/bin/APMrover2

I think what we need is:

  1. An updated RasPi image with the necessary GCLIB version patched-in properly (without having to switch to an unstable release). Rebuilding the source each time with older libraries may over-complicate support.
  2. A nice little ANSI download text GUI from Emlid (like raspi-config) which prompts for firmware type, configures auto-start of APM and also does a few of the other necessary tweaks to the standard RasPi image. That could be set to auto-start the first time, so Emlid have something like a plug-and-play image for newbies.
  3. The GUI could perhaps have an option to try latest and specific beta builds, effectively replacing all the functionality of the “firmware download” part of the GCS software.
1 Like


Really good, for now and medium term this script will help a lot….

I spent more than 6 hours do understand and fix the newer GCLIB issue, and manually delete and install evething again.

I am not a sysadmin. Does anyone know, whether it is necessary to start the firmware file with rt priority?

@dgrat no, there’s no need to do anything with the priorities because APM sets proper priorities during the startup by itself. rt(99) priority is for Linux critical stuff like watchdogs etc.

Is it just me, or could it be that since the update the variables in the EEPROM are screwed up?
All my PIDs have changed?! It is especially dangerous, since the rates of pitch and roll are not identical anymore.
Some other variables have been overwritten with zeroes or with very high values.
However, this could be easily also a problem of the GroundControl software. I have the feeling that the quality of MissionPlanner is abysmal. Maybe the one time I started this piece of utter code was already enough to overwrite the entries with random vaues :smiley:
Now I am pleased to recheck every variable…

I am confused about which repository I must build on. Is it the Copter-3.3 tag of diydrones or the emlid one…which has no Copter-3.3 branch? Is there any difference?

Thank you
Paulo Neves


Well indeed that is true, but if you check Emlid’s Building from sources, notice they have their own repository, which does not have the Copter-3.3 tag as I mentioned…

Building APM
These steps are the same both for compiling APM directly on Raspberry Pi and cross-compiling.
Download the APM’s port for Navio:
git clone GitHub - emlid/ardupilot: Emlid's port of ArduPilot for Navio/Navio+/Navio2.

For Navio and Navio+ boards switch to the ‘navio’ branch:
git checkout navio

For Navio Raw switch to the ‘navio-raw’ branch:
git checkout navio-raw

Navigate to the autopilot’s directory, for example rover, run configuration and build it:

And the Navio branch has 3 commits ahead of master…so they are different even.

Replying to myself I did a comparison between Copter3.3 and Navio branch and they match after all. The 3 commits ahead of master seem to be only related to the Copter3.3 release.

Hi, can you elaborate a little more on why you cannot sample SBUS? Maybe explain a little on how the DMA sampling works? I would like to try to get the SBUS input working. I have opened an issue on the Ardupilot Github for this item #2795.

Hi , I have followed your instructions to install latest APM , i see it comes up as 3.4 dev
if you change latest to beta in the firmware path you get 3.3 rc10
ie sudo wget http://firmware.diydrones.com/Copter/beta/navio-quad/ArduCopter.elf --output-document=ArduCopter-quad

I noticed in both versions that my current measurement shows negative for current (amps) and battery is always at 100%, (update if i arm and run motors it shows a positive while they are running).

Also i noticed Compass/Motor MOT is not working, i was able to run it with original release, but with 3.3rc 10 and 3.4 dev it fails.

I am unable to use Auto Analysis with mission planner lastest beta. and the Log Review does not show Vibes and vibes is not shown on Mission planner
I guess i should be using the beta 3.3 RC10 rather then the 3.4 Dev

Anyone else had problems with Compass/MOT ?

I also tried connecting a second GPS and compass (NEO7M) but the compass made the system run slow probably a conflict, the 2nd gps worked on its own if i unplugged the 2nd compass.

Anyone managed to get a 2nd GPS / compass working ?

I’m running beta 3.3 rc10, very well performance.

About second GPS, I don’t know for Navio+ board, I already test 2 GPSs with Pixhawk, but I Strong recommend you use only one GPS… look my post from diydrones, without answer.

But if you want go ahead, tests are good anyway, and help a lot the evolution.

about the current measument did you change the paremeters ? I have a strange baterry fail safe alert in pre-arm check, but the current measumnt is ok.

@DAS62 Thanks for the info I will also change my script to use the beta path then, not latest.

@robertb It seems like DIY Drones already split their development streams, I guess new features in 3.4 only, and 3.3 is just for fixes until it’s ready for release (it’s taking a long long time).

Shame because we need 3.3 before us Navio users can document/use a “stable” link with hardware support. I wonder why 3.3 is taking so long to release, I thought it was all very well tested (even simulated).

yes, Tonny, I agree.

So for now, I think is better one GPS

Hi there,
just in case someone is interested. I was testing RC9 with Pi2 and after updating the libc execution worked.
Today, I tested RC11 with Pi1 and it is not executable with the libc6 version :D.
I think downloading executables in linux is not a good strategy.
Additionally, pigpiod is running by default. I don’t know whether this is dangerous together with the new version of AP :slight_smile:
Maybe not, as one of my copters was flying a while with it… But it takes a bunch of CPU time.

Best, Daniel

Shouldn’t it be a package manager source URL/package in the world of Linux? Installation and updates would be even easier then.

I don’t mean going back to a separate Emlid build, just some kind of standard wrapper which helps with installation and updates.

If it doesn’t require a lot of infrastructure and can be duplicated to support the different flavours of Linux package managers, then DIY Drones should set it up on their web server which hosts the master files.

Isn’t a package repository simply some configuration files hosted on a server? i.e. possible to host statically and update (the internal source file URLs, dependency and version numbers) in their build script?

hi, here is a video with APM 3.3 rc9, my Y6 is in loiter mode
the GPS lock is pretty good, just noticed some variation in altitude
tomorrow i will test the rc11

1 Like

It appears 3.3 is officially stable since 9th September on firmware.diydrones.com (build 29th September):


commit 340970fc95a04da31895243efaf08436c75ded0e
Author: Randy Mackay rmackay9@yahoo.com
Date: Tue Sep 29 08:45:56 2015 +0900

Copter: version to 3.3


So now Navio has an official APM production release :sunny:

I’ve also updated the download script in this thread. Maybe it should go into the documentation?

@CodeChief We have new .deb ready, will post it today and update all the download links.

I wonder what the “normal” way should be. Now Navio is in the DIY Drones official build, why continue to maintain separate DEB files? Perhaps there is some technical reason I’m not aware of (still a Linux newbie), e.g. does it deal with the dependencies better?

The only outstanding issue with the direct build I am aware of is that we still need to use the “testing” branch of APT package manager, because DIY Drones use a newer C library. I guess we need a new Emlid real-time image/higher RasPi kernel to get that?