Auto Takeoff Sequencing Problem

I've been working with the Auto Takeoff macro and have experienced the problem where the throttle goes to "max" as soon as AUTO mode is selected. 

The documentation and other posts tell me that I should close the throttle and put the APM in AUTO mode.  Next I should advance the throttle off the lower stop.  Only then, when the airplane velocity gets to 3 meters per second, the APM should go to max autopilot throttle and pitch up to climb straight ahead to the target altitude.

Here is what does happen-  First, I load a simple APM flight plan. Waypoint one uses the Auto Takeoff macro with the max angle set to 15 degrees and the target altitude to 300 feet.  The second waypoint is a Loiter_Unlimited at 300 feet.  This sequence is really just a test of Auto Takeoff.

Once the flight plan is loaded, I walk the airplane up behind and put it on a bungee launcher.  With the throttle closed, I then use the transmitter to put the APM in AUTO mode.  At this point, the APM will consistently command max autopilot throttle.  And this happens with the transmitter throttle closed and the airplane at rest, "zero" velocity.


Other people have reported this same bad behavior.  You can see it demonstrated live in  MyGeekShow Episode 50 starting at 1:05 into the video.  He has completed a short checkout flight to verify Stabilize mode.  As soon as he switches to Auto mode, the motor spins up to takeoff power while he is holding the airplane overhead.  This is right after he tells the viewers that it will wait for forward motion.


Have a look - http://youtu.be/DR8JU5Qep0E

My setup is --

Airplane - X8 Wing

ArduPilot 2.5 with Arduplane 2.66

APM Planner 1.25 Mav 1.0

DragonLink RC radios

3DR Telemetry radios

JR9303 RC Transmitter

To investigate this in a safer environment, I created a testbed with an APM 1, GPS and DragonLink on a piece of balsa.  The throttle channel is connected to a 9g servo swinging a half-inch arm.  The APM 1 has the same ArduPlane 2.66 code and the same parameter set as the airplane.  I loaded the same flight plan via USB.

Disconnected from Mission Planner, the board gets powered up and I wait until the GPS has lock.  As soon as the JR switch commands Auto mode, the throttle servo goes to (75%) autopilot max.  Every single time and without exception.  It does not wait for movement, it just goes for takeoff immediately.


Here's the (procedural) solution-  You have to power up the APM and be connected to Mission Planner, either by USB or radio link.  You have to use Mission Planner to manually set the current waypoint to "Waypoint 1".  Once that is done, the Auto Takeoff macro will perform as intended.  With the transmitter throttle closed, it will go into Auto mode and wait.  When the throttle is advanced, this arms the code and the APM will advance its throttle channel after seeing about 8 mph.

I tested both the failing sequence and the successful sequence several times by putting the balsa testbed system on my dashboard and driving up and down the street.  Anyone should be able to duplicate this test and I would like to see others check my work.

As it stands, the Auto Takeoff macro is dangerous.  The APM code starts up on waypoint "zero".  The prop will spin as soon as Auto mode is commanded.  If the pilot is unprepared, this can easily cause injury and/or damage.  I don't know why ArduPlane starts on waypoint zero when every flightplan begins with waypoint one.  It's my guess that this is the aspect of the code that should be reviewed.

Please let me know and I will be glad to add this as a bug.

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

Join diydrones

Email me when people reply –

Replies

  • Thanks Michael! That's just what we need. Looking forward to seeing that code update.

  • Hi Andy,

    I've done a little investigation into your problem. I'm fairly new to the ArduPilot code but have been investigating auto take-off/landing for other reasons and thought I'd take a look.

    In terms of your having to change to Waypoint 1 to suppress the throttle, I believe the behaviour you are seeing is perfectly normal from the autopilot's perspective, and manifests itself in what you might think is weird.

    To put it simply: I think that by forcing Mission Planner to set the current waypoint to Waypoint 1 you are effectively bypassing auto-takeoff. The APM is now attempting to reach that waypoint and has skipped the take-off procedure. There is a throttle suppression method in the main control loop that follows a number of checks to suppress the throttle under certain conditions, including if the GPS derived speed is below a certain threshold. In this case, because you are still on the ground and not moving, throttle is suppressed. Put it in your car and start driving down the road, the GPS speed picks up, and throttle is no longer suppressed. There is a special clause in the throttle suppression check that un-suppresses throttle in auto-takeoff and ignores the speed check. I believe this is the source of your concern, and is reflected in Pieter's observation of the elevon behaviour.

    The easiest solution I see is to add another parameter that sets a minimum GPS ground speed threshold in auto-takeoff before allowing throttle. This should be user-definable: set it to 0 and the motor should start instantly when you switch to auto (good for ground takeoffs). Set it to say, 3 m/s and the throttle will not engage until you give the plane a hard throw or launch it from a catapult. I've written up some code to handle this. I do remember the same as you that this behaviour used to exist, but no longer does for whatever reason. Anyway, if you'd like to add an issue on github https://github.com/diydrones/ardupilot/issues?state=open, I can add my code that adds this parameter and (I hope) fixes your issue. 

    A note that I haven't tested this change myself and it will need testing by someone with the appropriate setup, but it is fairly simple so I don't expect any serious issues. The only one I can think of is the delay between launch and the GPS establishing a stable velocity estimate, so a lower quality GPS module may need some time to catch up and the plane may glide to the ground before throttling up.

    So let me know what you think. I'm also happy for others to weigh in if there is a better way to do it, or even just to tell me I'm wrong!

    Michael

  • I've had this same problem and posted about it numerous times. Never received a response. Agreed it's dangerous. Auto landing has some serious bugs,numerous posts on it as well but I'm not sure 3d robotics monitors the forums.

  • Andy,

    I'm having trouble setting up my Dragonlink to my APM 2.5 using only the PPM out of the RX which is channel 12 on the RX... I'm using a JR 9303 with Dragonlink v2 to APM 2.5 and I'm hoping you are using the PPM out also.... I went into the mission planner but was unable to change any inputs because as I moved the controls of my TX there were no movements in the setup screen even though I had movements in the servos I had plugged into the APM at the time....

    Can you please give me some pointers into how you went about getting the your outputs thru the APM to match your inputs from your TX please?

    Any information will be greatly appreciated!!

    Matt

  • Pieter,

    Thanks for posting, I was beginning to think that no one else in the DIYDrones community either sees this or considers it a safety issue.

    To your question-  AutoTakeoff is supposed to make the plane climb straight out until it reaches the altitude as set in that waypoint.  But, how does it determine "straight out".  A pilot looks ahead and picks out a reference point on the horizon, then steers for that point.  My understanding is that an APM2.x uses the current magnetometer heading, while the APM1.x will use the GPS heading.  GPS heading is unreliable when standing still.  I've seen advise to walk the plane forward to the launch point in the desired direction and this will set the takeoff heading.  Not the best solution, but it's what can be done with GPS.  So, when you observe the elevons, the APM is trying to turn to the takeoff heading. 

    I found another problem that happens for me after AutoTakeoff starts.  My second waypoint is a Loiter_Unlimited.  So, the documentation says the plane will climb straight out to initial altitude, then Loiter_Unlimited will make it circle at that point until I give it another command.  In practice, my airplane makes a climbing right-hand turn and then circles over the HOME position.  It seems to be skipping the Loiter command and going past it to an RTL.  So, you should consider what the next waypoint it asking for.  If your flight plan is like mine, then it may be doing the same right climbing turn to go back to the HOME position.  Have you tried the AutoTakeoff yet, and what does your flight plan look like?

    I've been working on battery and power issues since the initial post and I am somewhat astounded that no one commented, corrected me or acknowledged the "waypoint 0" problem.  After the holidays I am going to try several AutoTakeoff variations to see if I can make a better description of the problem. 

    Andy

  • Hi Andy,

    thanks for your great post! it really helps me. I've got one little problem still. When i let is stay on waypoint zero the motor spins and my elevons are in the RIGHT position (when plain horizontal the elevons 30 degree) but when i use you trick the motor is out (that is great) but my elevons are in the wrong position (one up /  one down like it wants to make a turn. Tomorrow I want to test de auto takeoff like you discribed for the first time but I'm afraid that this elevon situation will cause a crash? Do you have the same problem or do you have a solution?

    Thanks a lot, Pieter

This reply was deleted.

Activity

DIY Robocars via Twitter
yesterday
DIY Robocars via Twitter
RT @_JonMyer: 🏎 We need your help in naming my #AWS DeepRacer Underground Track 🏎 @davidfsmith's track is going to be referred to as 𝗔𝗪𝗦 𝗗…
Thursday
DIY Robocars via Twitter
RT @gclue_akira: 仕事もおわったし、電脳化にとらい #マリオカートハック https://t.co/4IU90hCLgm
Thursday
DIY Robocars via Twitter
This is the hashtag to follow all the people in Japan who are hacking the new Nintendo Mario Kart with the real AR… https://twitter.com/i/web/status/1319281354664677376
Thursday
DIY Robocars via Twitter
RT @gclue_akira: @chr1sa @diyrobocars jupyter mario https://t.co/P0oHdjlCRq
Thursday
DIY Robocars via Twitter
RT @_JonMyer: 🚨Our 1st AWS DeepRacer Community Race is Underway on http://twitch.tv/aws 🚨 Join us to find out which member of your commu…
Tuesday
DIY Robocars via Twitter
Monday
DIY Robocars via Twitter
RT @BackyardRobotcs: After an admittedly long wait, the new Tinymovr R3.3 motor controller is now available https://tinymovr.com 🥳
Monday
DIY Robocars via Twitter
RT @_JonMyer: 🏎 1 hr left before the #AWS #DeepRacer Community 🏎 Top 5 Race tomorrow LIVE on Twitch 1st Place = $50 Amazon GC or AWS Credit…
Monday
DIY Robocars via Twitter
Oct 16
DIY Robocars via Twitter
Oct 15
DIY Robocars via Twitter
Oct 14
DIY Robocars via Twitter
RT @davidfsmith: Race virtually with The AWS DeepRacer Community Race and then join us on the track to see how your times compare on the ph…
Oct 14
DIY Robocars via Twitter
Oct 14
Hiroki Tanaka liked Hiroki Tanaka's profile
Oct 13
DIY Robocars via Twitter
RT @breadcentric: It's now!
Oct 13
More…