Ardupilot 2.7 Beta

I was going to call it 2.6.3, but so many changes have been made, updates added, I think it requires a full point. Also, the header file has been streamlined a bit and some defines have changed. The PID gains have not, so if your plane flew well with 2.6 it will fly well, or even better with 2.7. BTW, this is the first release that has only been tested via HIL. I've never flown it for real because of the strong winds in the bay area right now. We'll see, but I think this will be the most stable release yet.

What's changed:

I've included a folder for connecting your ardupilot hardware to X-Plane. There are PNG files showing the configurations to make in the menus.

X-Plane supplies IMU data and airspeed data to Ardupilot so you must select the GPS_IMU option to connect.

New altitude estimation - Thanks to Ryan Beall for this one. This smooths out noisy altitude readings from GPS.

Takeoff and landing are now full features. Their use has been simplified and are assigned full flight modes which can be seen with a ground station.

New Fly by wire throttle command by Christof Schimd.

Updates altitude hold for those with airspeed sensors. Airspeed is now recorded in m/s instead of air pressure value. Since calibration for your particular pitot tube setup could be needed there is now a calibration value in the header file.

Improved stick mixing response for all modes.

Waypoints will be skipped if you miss them after one loop around. The number of degrees can be changed in the code so let me know how many is good.

Loiter hold has been improved.

Cross track gain now on by default.

Numerous bugs are gone.

Old, unused code and vars have been removed. Code has been reformatted and commented.

If you have any issues, please comment here and I'll get them fixed in the final release.

Jason

http://code.google.com/p/ardupilot/downloads/list

A note on the throttle failsafe function in the ATmega:

// mode TRUE is AT328p control of servos; this sets PD4 (pin 2) as an output and asserts logic high
// !!! we then have two outputs tied together (pin 2 of AT328p connects to pin 6 (output) of the AT45)
// !!! and selection of MANUAL mode via RC transmitter will result in logic low on AT45 pin 6
// mode FALSE sets AT328p pin 2 as an input and AT45 pin 6 controls MUX
void set_servo_mux(boolean mode)
{
while(TCNT1 < 20000){};
if (mode){
//take over the MUX
pinMode(4, OUTPUT);
digitalWrite(4, HIGH);
}else{
//release the MUX to allow Manual Control
digitalWrite(4, LOW);
pinMode(4, INPUT);
}
}

Perhaps we should let the ATtiny also read the throttle channel and move this function inside it. This would also have the advantage that runaway code in the ATmega can't prevent switching to manual mode via the control channel.

You need to be a member of diydrones to add comments!

Join diydrones

Comments

Developer

Michael Oborne August 10, 2010 at 3:29am

Hi Recmaster,

do you have wind turned on? i do know what you are saying, i dont send any commands to the nose wheel in xplanes and have noticed it jump around when your on the runway. i just ignore it.

Thanks
Michael
Recmaster August 10, 2010 at 3:17am

Yellow people!

Ive a strange bug with simulate by X-plane. At start plane doesnt go to WP1, it turning left at take off phase.
After change to AUTO mode, plane start going to WP1. I changed a start plane direction at X-plane but it doesnt cure.
I used this communicaton utilite http://vps.oborne.me/ardupilotsim.zip.

Then I use this http://vps.oborne.me/ArdupilotSim.exe com utilite, plane was going right, then left and take off.
What could be problem?
Mark Whitehorn August 8, 2010 at 10:35am

Jason,

Thanks for the info, I guess my Rascal 110 will get a Mega. I like the idea of a separate failsafe that guarantees manual control through the RC link though, and will try reprogramming the ArduPilot AT45 to read both the control and throttle channels. Since I'm currently flying under AMA rules, I've disabled the ATmega failsafe function by inserting a resistor between the pins mentioned above.
Developer

Jason Short August 8, 2010 at 10:26am

The throttle failsafe only works in Stabilize, and FBW.

Mega handles this completely differently. There is no way to assert control of the MUX from the 1280. There is the possibility of removing the mux entirely from future versions. This would make Jordi very happy... Doug is currently flying in "Software Manual" which is an alternative to the hardware mux. It does require stable code. The 1280 has far less RAM issues as well, which accounts for 95% of in air restarts and lockups.
Mark Whitehorn August 8, 2010 at 10:19am

My Spektrum AR6200 receiver goes to low throttle in failsafe, but keeps the current values of all other channels. If I were to fly out of range in manual mode, the AT45 would be asserting low on the mux select input, while the AT328p would be trying to pull it high. This seems to be a design flaw, since the resulting logic level may not be valid and worse, there will be a large current flow through both output pins.
I haven't looked at the Mega Failsafe wiring; is it done differently?
Developer

Jason Short August 8, 2010 at 9:53am

We had that for a little while in the Mega Failsafe but pulled it out. The problem is only a few people use the failsafe in this way. Accidentally setting it off while not expecting has caused some issues and we pulled it out.
I'm very confident with the current implementation right now. I routinely fly FPV out of range (1 to 1.5 miles) just for fun because I know it will come back every time.
Mark Whitehorn August 8, 2010 at 8:34am

A note on the throttle failsafe function in the ATmega:

// mode TRUE is AT328p control of servos; this sets PD4 (pin 2) as an output and asserts logic high
// !!! we then have two outputs tied together (pin 2 of AT328p connects to pin 6 (output) of the AT45)
// !!! and selection of MANUAL mode via RC transmitter will result in logic low on AT45 pin 6
// mode FALSE sets AT328p pin 2 as an input and AT45 pin 6 controls MUX
void set_servo_mux(boolean mode)
{
while(TCNT1 < 20000){};
if (mode){
//take over the MUX
pinMode(4, OUTPUT);
digitalWrite(4, HIGH);
}else{
//release the MUX to allow Manual Control
digitalWrite(4, LOW);
pinMode(4, INPUT);
}
}

Perhaps we should let the ATtiny also read the throttle channel and move this function inside it. This would also have the advantage that runaway code in the ATmega can't prevent switching to manual mode via the control channel.
Developer

Jason Short August 7, 2010 at 9:11pm

Thanks Juampa!
I'll take a look tomorrow.
Best,
Jason
Juampa August 7, 2010 at 8:37pm

Hi Jason, did you have the chance to take a look? Any comments?
Juampa August 5, 2010 at 1:23pm

Please note I worked on revision 1300, I just see is not the last one right now

of 9

This reply was deleted.