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: 4155

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.

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?


There seems to be a new problem with 2.66 and second aileron:

I use RC5 for the second aileron, manual settings like trim, and Servo Reverse do not work if I set them in RC ?!?

There is a difference between RC5_in and out I did not understand.

Also RC8_Trim is allways 1500.

Hi Greg,

I use RC5 for the second aileron, manual settings like trim, and Servo Reverse do not work if I set them in RC ?!?

The change that I make for 2nd aileron support was to make the output signal depend on channel 1 (the main aileron channel) rather than the input side of the 2nd aileron channel. For example, with RC5_FUNCTION set to 4 (which is 2nd aileron), the code would previously copy the pwm input from channel 5 to the output of channel 5 when in manual mode. The new code will copy the output of channel 1 to the output of channel 5. The change only affects MANUAL mode.

The reason for the change is that in all modes other than manual the input to channel 5 isn't used at all. The control of the 2nd aileron happens either based on the channel 1 input, or under auto control. I didn't want to require that users have an input channel setup on their transmitter for the extra outputs.

So I don't think the old code was right (and there was a "fixme" note in the code, which is what drew my attention to it), but I can see that if you have different reverse settings for RC5 to RC1, or very different trim/limit values then the new code will be a problem.

Perhaps the best solution is for MANUAL mode to calculate servo_in/servo_out values for these additional channels, and use RC_Channel_aux::set_servo_out(), just as is done in non-MANUAL modes. That will take a bit more calculation, but should allow for correct control in MANUAL without requiring that the extra channel be tied up on the receiver.

I'll put together a new patch for you to try. Sorry for the breakage!

Cheers, Tridge

hi...it`s possible to tune the
speed response of the servo in
the ap_ mount code?? because i
found the servo not compensate
very well...i use two hi speed
servo in mount pan and tilt....i
read the code and the camera
stab only refresh at 10 hz
thanks for your attention..and
hope your's help

Luis Carlos Barrios


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.

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 Tridge,

Thanks for the quick reply. I had to change one of the aileron servos in my Cularis. So one aileron has different values for min/max and reverse. I am a newbie but I will try to get further information about RC-Channel_aux::set_servo_out(). I would like to have still the seperate channel from RC. With my Auto_Flaps on channel 6 and 7 it still seems to work fine.



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,


Reply to Discussion



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

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service