I've just released ArduPlane 2.32
This is a minor update with 2 changes:
The new MANUAL_LEVEL option is a boolean option. If set to zero (which is the default) then the existing behaviour of doing automatic accelerometer calibration on every boot is used.
If you set MANUAL_LEVEL to 1 then it won't calibrate the accelerometers on boot and will instead use the values from the last time it did a calibration. The idea is that you get a good level once, then set MANUAL_LEVEL to 1. You can then redo the level using the mission planner or another ground station, or by setting MANUAL_LEVEL to 0 and restarting.
The compass learning change is based on feedback from the last release where noise in the magnetometer caused the learning to be quite bad for some people. The automatic offset learning should now be robust to quite large amounts of magnetic noise.
As Chris said, we fully support both APM1 and APM2. The only real differences between them are the moment are:
I'm committed to keeping the APM1 going for as long as possible, and we have no plans to drop support. In fact, some recent changes have allowed us to re-introduce more features onto the early 1280 based APM1 boards as we've managed to fit more functionality into a smaller amount of code.
Indeed, my APM 1280 board was flying like a winner under 2.31, I don't know if it was my imagination or the fact the conditions were so calm but I'm convinced it flew quite a bit more stable than previous releases.
Good work Tridge..
Sorry if I'm being a bit dim here, but how do I go about loading 2.31or 2.32 code at 51.4MB on to APM1 1280, given that it will only load about 1Mb of code, do I have to shave 50.4 MB off it?
Martin: the old 1280 boards were retired more than a year ago and are no longer officially supported (via the Mission Planner), but you can still load the code on them yourself with Arduino (only a tiny fraction of the source code turns into binary, so you can't compare source code size with hex file size). I don't have a 1280 board myself anymore, but I think you need to turn off datalogging to make it fit. Maybe Simon can tell you what option to put in the APM_Config.h file to do this.
Thanks for that Chris, I was just looking at the size of the code files on the current downloads section and hadn't appreciated that there were different file types loaded there.Whether source or hex, I thought that they would all be the same format.
A small correction. The 1280 load still works via the mission planner. There was a time when it didn't, but we managed to squeeze the code down a bit and you can now load 1280 firmwares for both ArduPlane and ArduCopter from the current planner.
Of course, that may change any time. The fact that the 1280 can still take a standard firmware load is partly luck. At some stage we'll no longer be able to fit it, as we certainly won't hold back development just to keep the 1280 alive.
PS: I have a 1280 based board in my telemaster
Good news and thanks for the correction!
Is the hard and/or soft iron calibration just based on default values or how is this accomplished?
I just ordered an APM2 and am curious if it comes with good default values for calibration or if there's a bit of calibrating required?
Regarding the accuracy of GPS altitude, there are a couple of techniques we use in MatrixPilot to improve altitude performance.
1. We deliberately delay initialization until 20 seconds after GPS reports a valid nav solution. GPS accuracy improves quite a bit in that time.
2. We offer the option of specifying the altitude of the flying field. This takes advantage of the fact that the GPS accuracy improves with time. And the way to determine the altitude of the flying field is to record the GPS altitude at the end of a long flight.
We currently wait for 5 GPS packets before considering it a good fix, but at 4Hz that's only just over a second.A 20 second wait would give a better fix certainly.
The main way we deal with GPS altitude problems is that we encourage people to use relative altitude for waypoints. The relative altitude is by default based only on the barometer, so the main problem with poor GPS altitude fixes is that the log files (which log the altitude of the initial fix plus the barometric altitude) tend to be a bit off.
It's still worth improving however. I think I'd prefer an approach of continually improving the altitude fix until enough movement is detected to fix it as home. So if you have a long startup checklist you'll get a longer fix. If you plug in and throw it in the air then it will work, but perhaps have a less good fix.
I also think we could also improve the barometer in the same way. I do notice that the first couple of minutes after the barometer starts up that it tends to rapidly change pressure and temperature while the electronics warm up. I tend to do a new calibration before takeoff, but it would be nice if that wasn't needed.
Yes the 5 GPS packets might be a bit too short time. Usually when GPS is powered up the VDOP/HDOP is poor for few seconds. Maybe the altitude and location calibration is good to be done after 30 seconds from power up.
I have noticed that when the first initialization is done right, there is no need for another calibration during flight.
if´ve just finished my Twinstar with the APM2 Board. (not flying jet)
So i do not know where to finde the option of the MANUAL_LEVEL.
Please could you explain where i can finde the Option and how to set it to 1 or 0?