I've just released ArduPlane 2.71 for your flying pleasure.

As was described in the 2.71-beta thread, these are the major changes from 2.70:

  • prevent control mode changes due to receiver input change when in throttle failsafe
  • auto-scale analog input based on board voltage. This also removes the INPUT_VOLTAGE parameter, as it is no longer needed
  • added TKOFF_THR_MINSPD and TKOFF_THR_MINACC parameters. These allow you to set a minimum ground speed or X acceleration before the motor is started in auto mode. This is to better support hand launching in AUTO mode, and bungee or catapult launching.
  • added TKOFF_HEAD_HOLD option. This determines if auto takeoff will try to hold heading while climbing out. For a hand launch it is often better just to hold the wings level, instead of trying to hold heading.
  • changed FBWB altitude control from elevator to lock in the altitude when the elevator stick is neutral. This fixes a problem with altitude changing in FBWB mode due to slight tuning errors. You can set the climb rate for FBWB with the FBWB_CLIMB_RATE parameter. It default to 2 m/s
  • auto-detect when the compass is way off due to interference and switch to GPS navigation until the compass is healthy again. This is designed to prevent flyaways due to very bad magnetic interference.
  • prevent servo output overflow on large PID gains. This is especially important for elevon aircraft
  • changed default STICK_MIXING behaviour to use FBWA style stick mixing in AUTO mode. This prevents the pilot from causing radical turns if they don't know that the plane is in an AUTO mode. You can get the old behaviour by changing the STICK_MIXING parameter to 2.
  • Added a software VTail mixer, enabled using the VTAIL_OUTPUT option.
  • Fixed loading of missions with DIGICAM control commands, so DIGICAM control works again
  • Don't trigger a GCS failsafe if the GCS has never connected
  • Fixed fence MAVLink target IDs (fixes a problem with AndroPilot)
  • Added HIL_SERVOS parameter to allow real servos to move in HIL mode
  • Fixed an off-by-one in PX4 channel output (last PWM output channel wasn't sent)
  • Fixed scaling of joystick speed when controlling a camera gimbal with a joystick
  • Fixed creation of APM directory on SDCard on PX4
  • fixed auto-config of uBlox baudrate for uBlox modules set to 9600 baud
  • Fixed PX4 startup in FMU only mode
  • Added APM/boot.log on SDCard on PX4

Many thanks to everyone who contributed to this release!

One thing that isn't in this release but will be in the next release is the new L1 navigation controller from Brandon and Paul. They are doing fantastic work and testing is good so far, but I wanted to get the new features above out first before adding the new navigation code. I hope we will release a 2.72 release with the new L1 controller in the next couple of weeks.

Happy flying!

Cheers, Tridge

Views: 11749

Reply to This

Replies to This Discussion

When I try to enter the measured voltage from the UBEC less the 0.3 volts to enter for calibrating the current & voltage sensor it give an error "Not Available"   Ive selected all the correct settings all the same as when it worked on my quad. What ever I enter in the field #1 wont stay there. Why would that happen?

And also. how much influence does the Baro have when the APM1 is used for the Arduplane? On the Arducopter it is quite sensitive and it is mixed with the sonar and GPS for fixing height. Any airflow onto the board can give very bad flight behavior so it needs to be covered with foam to protect it from air movement.

I assume this is not so sensitive for the Arduplane? I see many setups with an open canopy where a lot of air would be flowing into the body of the plane, which would normally affect the baro quite a lot if this were an Arducopter.

Also I see my Home altitude is now at 154m so I assume this is  ASL?  It was at 0m until I got it to get GPS lock for the first time and now its on 154m.

Hi John,

The INPUT_VOLTAGE option was removed in ArduPlane 2.71 as it is no longer needed. The code now reads the input voltage itself internally, by comparing to a CPU reference voltage.

So you can't set it now, as that option is removed. Another area of the docs that needs updating! This month is going to be documentation month ...

Cheers, Tridge

The baro is sensitive to airflow, so you should have it covered.

Also I see my Home altitude is now at 154m so I assume this is  ASL?  It was at 0m until I got it to get GPS lock for the first time and now its on 154m.

The MissionPlanner currently displays the VFR_HUD.alt variable, which is home altitude in MSL plus the barometric relative altitude. Internally APM navigates with barometric relative altitude by default.

Cheers, Tridge

Thanks for clarification and the quick reply Andrew.  On the baro question, ( I would always cover it anyway)  On the copters if you put a cover over the APM board without holes in it and you descend, it builds up pressure and then give the baro the impression its dropping faster than it actually is, soit tries to adjust for it, and in doing so it cause it to bounce up and down. You can see a similar example of this on Randys test video for ArduCopter 2.9/2.9.1b release where he gets sudden drops after accelerating forward.

So what I am curious about and if its already been noted as an issue, if I still have the baro covered and away from any direct wind, but say for example the vent holes in the front of the fuselage are larger than the holes at the rear, where I assume there should be some slight build up in pressure inside the fuselage, will this give strange flight behavior as we saw with the Arducopters? 

To avoid this we would have to have the air going in and out of the body fairly balanced. Has this been a issue discussed previously?

See posting on this for Arducopter http://diydrones.com/forum/topics/barometer-issues-and-pid-tuning

I want to get the whole 180 from left top right on pan from my camera servos but I only get about about 160 and I don't get the full 180 throw. I have the manual adjustment setup on the two var knobs and I have set the end points in the TX to the max at 145. But I still don't get the full 180 throw for the pan. I also set the max in the gimbal setup Servo limit at 800 and 2200 and Angle limits to 90deg but still dont get the full 180deg throw. Any idea how to fix this?

I have the same problem. it looks like the labels for AHRS_ORIENTATION are not correct. I have my board rotated 90 counter clockwise from the pilots point of view ie the "top" is now pointing at the port wing and the only setting that would make it work was #20 which is labeled Roll270Yaw45 ... 

@Tridgell, I am using arduplane 2.71, when i give level command, i always get error, "ap 2.2+ required" It does levels once in 10 times. but most of the time it gives error. This happens with all the three APM 2.5 I have. but when i connect APM2.5 to USB the level command always works. The problem occurs when i use 3DR for connection. thanx

The latest version is V2.78 and it is really worth upgrading as there are many fixes to bugs and errors in the old code.

It may fly OK but you will be flying with potentially buggy and dangerous code. V2.78 fixes a lot of problems.

(also I don't think Tridge will read this and anyway support for the old code scratchy at best)

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service