I just worked this out from @george.staroselskiy’s extremely useful post here (regarding missing GCLIB 2.15+):
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”).
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.
Create the script below to help you download and run APM direct from DIY drones latest APM build (the first supporting Navio):
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.
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.
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.
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
Now I am pleased to recheck every variable…
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.
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 ?
@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).
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
Maybe not, as one of my copters was flying a while with it… But it takes a bunch of CPU time.
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?
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?