March 14 flight report: testing ArduPilot 2.5 RC 2 code
Jason Short and I had great day of testing and improving code (and putting in a pretty good T3 contest time!). Once again we were at the RC club in Point Richmond, across the Bay from San Francisco. Jason was just back from a skiing vacation where he tangled with another snowboard to the tune of 17 stitches on his ankle (I saw them: ouch) but fortunately UAV development doesn't require a lot of running.
You can see what flight testing looks like above. I fly, he watches the telemetry and then makes changes in the code for me to test.
Here's the rundown of the day's progress. You should see all this reflected in the code in the repository in a day or so:
The Good:
--Navigation is now locked in pretty well. Straight lines to waypoints (no more snaking) and pretty tight turns between them.
--Manual throttle control now works in autopilot mode! Just like you can "nudge" the plane's direction with RC controls while it's flying autonomously, you can now speed it up or down. Excellent for finding the best speed for T3 runs!
--The funky thing with one of my Futaba FASST receivers working and the other not was solved. Turns out that one of them outputs the PWM on all channels in serial, and the other in parallel. Who knew? Anyway, ArduPilot can handle either. If your radio does something weird like only letting you fly left, not right, edit this line in the config file:
//3-2
#define RADIO_TYPE 0 // 0 = sequential PWM pulses(Fasst, Spektrums), 1 = simultaneous PWM pulses (Corona RP8D1)
--We flew the FunJet in RC mode (although it has an ArduPilot, we haven't set up elevon mixing yet). Amazing performance: fast, rock solid and incredibly maneuverable. Once we get it dialed in with the AP, we're going to be looking at sub 10 second Sparkfun runs ;-)
The Bad:
--We still don't have altitude hold working right. We finally got it to display the right altitude in the ground station, but for some reason it's not holding. Jason thinks this is just a matter of tweaking throttle and pitch gains, but for now I had to trim the pitch down manually for the T3 trial runs just to ensure the plane didn't get too high during the autonomous portion.
--We're getting different results with different sensors. I'm flying with FMA sensors, and Jason was flying with DIY Drones sensors. The calibration routines should mean that as long as you've got a matched pair it shouldn't matter where they come from. But for some reason it still does, and different sources require different gains in the code. We'll figure out a way to make that go away...
The Stupid:
--I almost crashed one time by launching with stabilization accidentally on, but not yet calibrated (it takes a few second to calibrate in the air). Also we found that if you happen to power on in stabilization mode, it messes up your waypoint settings (for some reason it thought it was starting on waypoint 7), so for now just don't do it until we can find and fix that bug.
--I also almost crashed launching downwind. In my defense, the wind shifted direction. But still!
--I nuked another Xbee by powering on with the signal line attached. I can rescue it, of course, but I CAN'T WAIT for ArduPilot Mega to make this problem go away with the dedicated serial lines.
-
Developer Comment by jasonshort on March 14, 2010 at 10:27pm -
Hi Chris,
The Waypoint 7 issue was the air-start trying to finish the waypoints from the last flight. A ground start would have reset that one.
I'll post the code updates tomorrow once I give them a sanity check. I continued to fly but never could get my plane to fly as well as yours so no personal entry for me. I cut down my oversized rudder, but not enough I guess.
My guess on altitude hold is the pitch comp is too high and with constant turning and high throttle the plane is always pitching up. I'll work with Doug on that one.
You'll see on your KML file the wind direction. The plane oversteers a bit. I'm going to turn the gains down when we loose groundspeed so that should help.
Overall I'm surprised how fussy the plane was to dial-in, but once we did, it flew really well! I think we spent about 2-3 hours tweaking the code and gains. And, then it handled completely differently on my plane with identical setup except for the larger rudder and different IR sensors!
-
Developer Comment by Ryan Beall on March 14, 2010 at 10:35pm -
Two comments:
Hard to dial in = control laws and equations that are non-conventional make it hard to predict and pass sanity checks
Pitch comp: set it to zero until you have your altitude/ airspeed under control. I don't even fly with it because my alt/aspd hold is so tight!
-
Developer Comment by Ryan Beall on March 14, 2010 at 10:37pm -
Thirdly: The oversteering due to wind can be solved by deweighting the gain based on ground speed as Doug is doing in 2.5.1
Good work guys keep it up!
-
Developer Comment by jasonshort on March 14, 2010 at 10:57pm -
Here were the main issues:
- the IR sensors needed to be scaled to output the correct roll - they were under reporting, giving flat turns
- the roll was limited in v2.4 to 35 degrees which was scaled proportionally by .7 to 24 degrees - too modest, we upped that to 45 degrees and .8 proportional and had great turns.
- the slew rate was too slow on the smaller rudder - speeding up prevented oversteer
- pitch was showing a shallower angle than roll in comparable orientations - I still don't know why
- Pitch comp was too high causing the alt gains
-
Developer Comment by jasonshort on March 14, 2010 at 11:02pm -
By the way we pulled a 21 second loop around the virtual SF building...
-
Developer Comment by Mark Colwell on March 15, 2010 at 7:15am -
I wish I had someone from DIY Drones to help with flight tests, it would help a lot. It is hard to do all this by yourself. That's why I record video and TM, but then I need to review all this data, then make smart adjustments. It's the last part that gets a bit sticky.. I might not crash so much, with a little help too.
-
3D Robotics Comment by Chris Anderson on March 15, 2010 at 7:55am -
Mark,
I'd suggest you start with a more standard plane, like an EasyStar, and get experience with the AP. Then when you switch to a elevon plane like the Stryker you'll be tweaking fewer variables.
-
Developer Comment by Mark Colwell on March 15, 2010 at 8:26am -
I started that way, but that won't win the SF competition. I understand the PID tuning process well, just can,t get enough air time, to test. When I set I values 100 times to high (by misunderstanding) it kills planes, with a fast plane, you don't have much time to recover when AP is waco. I will now test with FligtGear 2 sim but I need a decent aerodynamic model of Stryker for this to work.
-
3D Robotics Comment by Chris Anderson on March 15, 2010 at 9:13am -
Mark,
I'm going to be adapting ArduPilot for a FunJet (and the IMU version for a SkyFun) over the next month, so that should help with elevon tuning. You're on the bleeding edge, so my hat's off to you!
-
Developer Comment by jasonshort on March 15, 2010 at 9:43am -
If its any consolation, I bent my new EasyStar wing last night after a terrible spin. I was able to land it but from now on I'm using full carbon spars.
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
Documentation Editors
51 members
-
ArduCopter User Group
1299 members
-
Melbourne
48 members
-
UK Ardupilot Group
111 members
-
Agricultural UAVs
137 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
You need to be a member of DIY Drones to add comments!
Join DIY Drones