First and foremost we’d like to thank you all for your awesome Navio projects.
Today we want to let everyone know that APM has reached the new milestone, i.e. Release Candidate 8 (rc8) that includes various improvements (vs current deb package version) that affect Navio.
There’s a bunch of experienced users on this forum and we’d like to hear your suggestions and bug reports. Although this is not a final release, we suggest you to test it either way. The Navio related code is pretty much stable now. We really encourage you to flight test the new code and let us know if anything’s wrong. You can also skim this thread which contains a ton of useful feedback. It’d be terrific to use the thread you’re reading right now for reporting Navio related issues.
The most important changes are:
Major AK8963 magnetometer and MPU9250 rework
From now on the annoying AK8963: BAD DEVICE ID as well as the APM relaunch failures should be gone
The transaction speed was increased
Connectivity stack rework
A lot of petty little bugs fixed that’d yielded some obscure error messages such as “Read failed - success” have been eliminated.
UDP reconnect. Even if a Wi-Fi dongle falls out, the connection is reestablished. If network interface is not up during the boot, the new code will pick up the slack.
RCInput reimplemented
pigpio dependency eliminated
CPU load significantly reduced thanks to getting rid of redundant 1 KHz thread.
ToshibaLED is now supported
Airspeed I2C sensor supported
The RCInput rework must make the FIQ USB driver work now (devs only. USE WITH CAUTION).
As soon as APM 3.3 comes out, we’ll update the deb package. For now we suggest you to use the beta builds or compile the code using the appropriate Copter-3.3 branch.
We’ve updated our repo and now navio branch is in sync with diydrones/Copter-3.3. We’ve also added a new experimental feature in navio-experimental branch on top of diydrones/master. The feature adds support for hostname resolution.
From now on one can launch APM like this:
sudo ./ArduCopter.elf -A udp:\<hostname\>:\<port\>
I must repeat once more that this is an experimental feature. But I do think that since it’s anticipated, it’ll soon make into master. The more feedback we get, the sooner it’ll get there.
Yesterday, I tested this new release (rc-8) , in Stabilise, Posholt, AltHold, etc….
And I’m surprised with results. Really, really good (for me :) ).
Looks like the commands are more “precise”, in stabilize looks like AltHold….
Telemetry over 4g works fine too with Mission Planner.
My motors are very “strong” but I never flew with so strong wind,
attached only I short video in stabilize mode….very good flight even with strong wind.
Congratulations, this new release looks very good for Navio+ board.
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.
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.
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.
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?
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.
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!
very good…