I've just released ArduPlane 2.66

This release fixes a number of small issues in 2.65. In particular

  • fixed auto-takeoff if you mission specifies a 0 value for latitude/longitude in the TAKEOFF command. This makes auto-takeoff missions easier to setup with Mission Planner
  • fixed doc strings for loiter radius to reflect new larger maximum radius. This should allow a loiter radius above 127 to be specified in Mission Planner
  • Added support for altitude override from Mission Planner in auto (thanks to Michael)
  • allow battery voltage/current pins to be set to different pins (thanks to Randy)
  • added differential spoiler support for elevon planes (thanks to Xichen Shi). This isn't documented yet, but hopefully will be soon.
  • fixed control of additional aileron channels in manual mode (so they follow the main aileron channel)

There are a lot more things being worked on right now, but I decided to get this out as a stable release update before putting in lots of new code.

Happy flying!

Cheers, Tridge

Views: 3998

Reply to This

Replies to This Discussion

Awesome, my GPS vs Mission planner problem has gone away with 2.66. Thank you....

Well it seems I spoke too soon. I've attached logs this time. The first larger log shows the mission planner displaying GPS properly, the second one doesn't. The status window shows number of sats but no position. As I've said before, this is definitely firmware related as 2.5 or below does not display this behavior. I am sorry to harp on about this, I do realise the devs have their own lives too. 

Thanks again, 



And I've found the bug... The trouble lies with the parameter AHRS_GPS_USE. When set to 0, the mission planner stops "seeing" the GPS data from mavlink.

this is my first look at the logs, and this is what i spot

on the good log

31/10/2012 12:35:36 PM FE 1E 72  1  1 18 mavlink_gps_raw_int_t time_usec 522758000 lat -411818609 lon 1749809164 alt 55550 eph 243 epv 65535 vel 2 cog 6037 fix_type 3 satellites_visible 8  Len 38

31/10/2012 12:35:36 PM FE 1C 80  1  1 21 mavlink_global_position_int_t time_boot_ms 523291 lat -411819776 lon 1749810560 alt 55460 relative_alt 10090 vx -10 vy -1 vz 0 hdg 18887  Len 36

on the bad log

31/10/2012 2:33:54 PM FE 1E 44  1  1 18 mavlink_gps_raw_int_t time_usec 477321000 lat -411818430 lon 1749809418 alt 56250 eph 161 epv 65535 vel 8 cog 35953 fix_type 3 satellites_visible 9  Len 38

31/10/2012 2:33:55 PM FE 1C 4E  1  1 21 mavlink_global_position_int_t time_boot_ms 477652 lat 0 lon 0 alt 56280 relative_alt -500 vx 1 vy -16 vz 0 hdg 27582  Len 36


i need to look further into why the position_int isnt being correctly populated by the AP

ok, I see what is happening now. The GLOBAL_POSITION_INT is populated by the AHRS object, and Hans had set AHRS_GPS_USE to 0. So the AHRS was not using the GPS.

Hans, can you explain why you are setting AHRS_GPS_USE to 0? That is normally used only to test the dead-reckoning code, so you use it when you don't want the GPS to be used for navigation. You still get GPS_RAW_INT in the logs, which means you can compare the true position of the plane to the dead-reckoning position.

Cheers, Tridge

Hi Andrew, 

It goes something like this: My APM is currently bolted to a mock-up of  the interior space of my airframe along with all the other electronics (telemetry, servos, pan-tilt, FPV gear, etc). In the time I have in between glassing the airframe I'm going to be installing it in I use this setup to test for telemetry and FPV range, to deconflict RF interference and for getting used to arduplane (I've moved to fixed wing from quads). When I'm done, I'll simply migrate it into the airframe as it's a scale model of the interior. Hopefully this will cut down on the time I have to spend debugging the whole system.

As this ground test rig remains static, the GPS input into the AHRS is:

a) largely irrelevant because it can't obtain "trend" values, such as course 

b) annoying, as it causes the artificial horizon to wander around 

I hope that answers your question. If I may ask, what mixing ratio fot the GPS data to gyro and mag data would you recommend as a good starting point? I've already gathered that the GPS course data may be superior to the MAG data on long flights at a relatively high speed. What about the attitude mixing ratios?

Thanks again,


Thank you guys -  ArduPilot rocks!
As i am a newbie and can't get RSSI reading from PIN 8 (I always get rssi=0) , i was hoping 2.66 will support rssi natively and there will be no need for coding and compiling. i did try however to compile 2.65 with RSSI support (reading many posts on this matter) but still nothing.


Any News regarding RSSI in 2.66 / MP 1.2.15?



Are you trying to get RSSI in the mission planner?

If so I don't think it supports it yet. The RSSI and RemRSSI are for the 3DR Radio set. I was thinking the same thing, but was getting RSSI on my OSD and on my ANT Tracker, but always a 0 in the mission planner. After swapping my Xbee for the 3DR radios they display info.

Maybe we can get Michael to add it for us.

Hi Navigant,

To make it easier to use receiver RSSI I have added a new option RSSI_PIN for the next release (ie. 2.67). This will allow you to set which pin is used for receiver RSSI without recompiling.

Cheers, Tridge


Thanks ! :>

Saw the changes for the RSSI in the source code, don't fullly understand it, but also looks like it needs a change in the mission planner for parameters (167)?

If so could the RSSI for the RX for plane control also be displayed in the mission planner?



Hi Burt,

You can use the "advanced parameter list" screen in MP to set the RSSI_PIN option. It should also show up in the standard parameters list soon.

Cheers, Tridge

for displaying the value in MP, that is up to Michael Oborne.

I'll mention it to him.

Cheers, Tridge


DIY Drones Monthly


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2016   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service