Hi there,
I was not testing now (maybe later), but does the new implementation of RCInput support SBus?
Theoretically it should, because the functions for evaluating the signal is within RCInput in AP_HAL.
Best, Daniel
Hi Daniel,
Even though RCInput can handle both signals we can’t sample s.bus over the DMA.
I like the current state of the branch a lot.
The hostname resolving feature is a nice addition.
Will test it on the big copter when completely successful on the small one.
Was also thinking whether it is possible to test the firmware with a tracer.
I guess I will try to build with e.g. valgrind support.
Yeah, that’s definitely possible! valgrind is really heavy on CPU, though.
I got pretty neat results with perf_tools a couple of months ago. I encourage you to click on the link! I personally think this kind of low overhead analysis is incredibly awesome and darn gorgeous.
We’re looking forward to your feedback!
I think debugging/tracing and logging is one of the biggest advantages of Linux in comparison to Pixhawk/APM2.
Additionally, one has access to all higher level libraries in the world.
Unfortunately, the ArduPilot library has to be completely backward compatible with (old) platforms.
Hi there,
I was building the whole library again with my cmake scripts and the compiler complained.
I don’t know exactly which flag at which point is hiding the errors in the AP build system,
but the pointer to int conversion would lead to problems on some platforms (and in my case build errors).
I wrote a small commit using the standard intptr typedef. I would suggest to get this reviewed.
I know it is likely not that important for 32bit ARM, but platforms may change later.
Link: RCInput - Navio by dgrat · Pull Request #2698 · ArduPilot/ardupilot · GitHub
Best, Daniel
1 Like
Sorry Daniel,
Can you explain I little bit more “noob” driven?
I running rc8 release, I have to upgrade or change anything?
Because this next weekend I will do lots of tests, and I would like to test the latest release version
other question please.
how can I reset all the APM parameters ? and what’s de procedure to install a fresh copy with standard parameters?
Thanks a lot.
No need to upgrade, I don’t even know whether commit will get accepted.
It will have anyway no influence for the users.
The commit would be important for 64 bit platforms as the current code looks like it will only work with 32 bit systems.
I overlooked that earlier. I just replaced the type conversion to be general working on any system.
3.3-Rc9 is available??? 
very good…
lets test…
congratulations really fast…
I’m getting:
./ArduCopter.elf: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.15' not found (required by ./ArduCopter.elf)
I’m trying to use 3.3-Rc9. A google search suggested I update libc6 but it’s already the latest version. Any ideas?
Yeah, thanks for reporting! I always compile APM from source. That’s why I haven’t spotted the error.
I’ve come up with a kinda dirty and obnoxious hack to get us going until the daily build on the build server is fixed. These are steps:
- point apt-get to use testing rather than wheezy repos
To do that you need edit/etc/apt/sources.listand change wheezy to testing sudo apt-get updatesudo apt-get install libc6
After it’s done upgrading the libc version will be 2.19. After that you can safely launch APM.
CAUTION: it may break something
2 Likes
Hello, guys!
Thanks a lot for your feedback once again. I wanted to let you know that the rc9 has been released as @robertb had already said above. We’re waiting for your new comments!
Dears,
3.3-RC9 with Navio+ is not good… Is “Perfect” 
more than 6 batteries packs tested today… althold really good, and PosHold Rock solid.
Thanks a lot for the Developers from Emlid and APM, really a very good combination.
a short vídeo
4 Likes
Are there instructions on how to load the test versions onto the raspberry pi and how to delete the old version I’m currently using?
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):
~/APM/Download.sh
#!/bin/bash
# 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:
- 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.
1 Like
Tony,
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 
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