There has been a lot of development activity in ArduPlane lately, and 2.60 is shaping up to be a major release. I'll cover the main points below and I'd also like to get some feedback from ArduPlane users on some of the changes.
Wind Estimation
The AHRS library will now do wind estimation while flying. It does this in two ways. If an airspeed sensor is fitted and the plane is not turning, then it uses the simple method of
wind = gps_velocity - airspeed_in_earth_frame
A low pass filter is applied to smooth the result. When the plane is turning or an airspeed sensor is not available, it instead uses Bill Premerlani's wind estimation algorithm, which was ported to ArduPlane by Jon Challinger. This uses the aerodynamic properties of an aeroplane to estimate wind by the effect on the planes attitude, combined with ground speed.
The resulting wind estimate is logged over MAVLink in a new 'WIND' message. The wind estimation code has been tested both in the simulator and in real planes and performs very well. It is in the master git repository now, ready for the next release.
Dead Reckoning
With a wind estimate available it became possible to do long term dead-reckoning. This now kicks in automatically when GPS lock is lost. Previously ArduPlane would stop attempting to navigate when it lost GPS lock, and it would also stop doing acceleration compensation. It now uses the wind estimate plus airspeed (if available) or the last GPS speed (if no airspeed available) to estimate the planes ground velocity vector. This allows it to keep navigating for quite a long time - it should be long enough to allow the plane to RTL from several kilometres away.
The dead reckoning has been tested a lot in the SITL simulator, plus has been test flown in 7 m/s winds by Jon Challinger, with great results. Jon's plane was able to loiter accurately with no GPS lock for a couple of minutes (and probably could do so for much longer).
Note that you need to have a compass enabled for dead-reckoning to work, as otherwise gyro drift will throw off the yaw. It will also work much better with airspeed than without.
The dead reckoning code is in git master ready for the next release.
Wheeled takeoff and landing
We now have support for steering a plane on takeoff/landing using a wheel coupled to the rudder. This allows you to perform auto takeoff and landing with wheeled planes.
To do a wheeled takeoff you need to setup the WHEELSTEER PID. I'd suggest you start with WHEELSTEER_P=1 and WHEELSTEER_I=0.3. Then test the steering by setting THR_MAX to a value small enough that the plane won't takeoff (eg. THR_MAX=15) and try an auto-takeoff. While it is rolling along the runway use stick mixing on the rudder to deliberately take the plane off course, and check that it comes back on course quickly but without oscillating.
New 'OBC' failsafe system
As part of the CanberraUAV teams entry in the Outback Challenge we've been developing a new failsafe system for ArduPlane that allows us to meet the OBC rules. The way it works is that you say what waypoint to change to for each failsafe condition. So you set FS_WP_GPS_LOSS to a waypoint number for when GPS lock is lost, and FS_WP_COMMS to a waypoint for when ground station heatbeats stop. You then setup a mission to do whatever you want at those waypoints. In our case we have waypoints setup to loiter for 30s on GPS lock loss, then fly to airfield home. If the GPS comes back, the plane will automatically resume its mission where it left off.
The new failsafe code is a compile time option, enabled by setting "#define OBC_FAILSAFE ENABLED" in APM_Config.h.
To support this new code there have also been fixes to some of the mission commands. For example, the LOITER_TIME now correctly takes the number of seconds to loiter, and you can ask the plane to "loiter in current location" by setting lat and lng to zero in a loiter.
New controllers
The other big change planned for 2.60 is the new roll/pitch/yaw controllers that Jon Challinger has developed. You can read about those on Jons blog. Those aren't integrated into master yet (mostly because I haven't test flown them myself yet). Jon has been flying them a lot in his E-Flite Apprentice with great results.
There have been lots of other smaller changes, but the above are the highlights. Please test out master if you get a chance and give some feedback before the release!
Cheers, Tridge
Replies
Nice, very nice.
Andrew
Any work on outputing RSSI info?
Just a few lines of code to send a value 0 to 255 on the "mavlink_msg_rc_channels_raw_send" message?
Right now it is fixed at 1.Some code like this would give the MiniOSD a way to display it.
static AP_AnalogSource_Arduino RSSI_pin(8); //on amp1 is A7 pin closes to xbee pins.
temprssi = RSSI_pin.read_average(); //need rssi to be 8 bit value so div by 4, highest value is 1024
temprssi = temprssi - 4;
if (temprssi < 0 ){
temprssi = 0;
}
rssi = temprssi / 4; // by now rssi should be 0 to 255, on decode * by 4 for full value, lose 4 points
This code in the sensor.pde.
A new rssi value, and of course to comment out the rssi = 1 in the GCS_Mavlink.pde.
A lot of users could use it.
On the Miniosd side the voltages that the various RSSI outputs, could be set for high and low values and output a % on the screen.
Thanks
Burt
Hi,
I wonder whether anybody else has problems with this current code and 2 aileron servos (i.e., RC_5 aux is the second aileron servo)? That worked fine previously but now behaves very strangely. Essentially deflaction into one direction is OK, but the other side becomes extremely sensitive (essentially moving from neutral to complete deflection in an instant). This happens for example in FBWA. Strangely enough, the first few seconds after rebooting all is fine. Only say 30 seconds later this takes effect.
I noticed that there were quite a few changes in the RC_Channel library. Most notable, the ANGLE_MIN and ANGLE_MAX have disappeared. So my suspicion is currently that something broke in the process. Still trying to track this down, once I have a lead I'll post an issue I guess.
Cheers, Andre
Hi Andrew,
Thanks for your great job! Will be possible to compile this new version on the olds 1280 APMs?
What about RSSI and a second battery voltage readings? Any news? :)
http://code.google.com/p/ardupilot-mega/issues/detail?id=687&so...
Regards from Spain,
Dario.
Andrew,
Thanks a lot for the work and for keeping us in the loop! I'd also have a few questions that I may figure out myself looking at the code but since they are of general interest to APM 1 users I think they could be asked here:
- Chris mentioned something of taking away the CLI switch code. Personally, I'm a big fan of the switch and since it's there on the hardware I'm happy to use it. Can you confirm that it's still there just #iffdeffed out as previously also?
- The new features that are gonna consume lots of flash, are they also possible to #iffdeff out? (thinking of the APM 1280 here). I'm interested in the new controllers and possibly wind estimation but don't really need the other things IMHO. I suppose I could branch off the master but it would be nicer to stay closer to the code base.
Anyway.. thanks again,
Andre