Replies to This Discussion

DeveloperPermalink Reply by Andrew Tridgell on March 29, 2012 at 6:44pm

Hi Brad,

As Chris said, we fully support both APM1 and APM2. The only real differences between them are the moment are:

• the APM2 has better quality sensors, so it will tend to track better
• we now tune the gyro drift rate controller differently for the APM1 and APM2, as we know the APM2 gyros drift less

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.

Cheers, Tridge

• ▶ Reply

Permalink Reply by Simon Amstel on March 30, 2012 at 1:58am

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..

• ▶ Reply

Permalink Reply by Martin Poller on March 30, 2012 at 11:31am

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?

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on March 30, 2012 at 11:44am

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. 

• ▶ Reply

Permalink Reply by Martin Poller on March 30, 2012 at 12:42pm

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.

• ▶ Reply

DeveloperPermalink Reply by Andrew Tridgell on March 30, 2012 at 2:18pm

Hi Chris,

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.

Cheers, Tridge

PS: I have a 1280 based board in my telemaster

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on March 30, 2012 at 2:31pm

Good news and thanks for the correction!

• ▶ Reply

Permalink Reply by Jake Stew on March 30, 2012 at 12:33am

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?

• ▶ Reply

Permalink Reply by William Premerlani on March 30, 2012 at 4:16am

Team,

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.

Best regards,

Bill

• ▶ Reply

DeveloperPermalink Reply by Andrew Tridgell on March 30, 2012 at 4:36am

Hi Bill,

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.

Cheers, Tridge

• ▶ Reply

Permalink Reply by Veikko Vierola on March 31, 2012 at 5:57am

Hi, 

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.

• ▶ Reply

Permalink Reply by Andre Meier on March 30, 2012 at 4:16pm

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?

many thanks

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page