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.
Replies to This Discussion
-
Permalink Reply by David Marra on -
yeah, I lucked out with the Futaba T9CAP. The PPM stream was perfect.
I had tried to get this to work a few months ago, but concluced the DL docs were wrong, I revisited it the other night and sorted it. So nice to have the single cable for PPM instead of the individual PWMs.
-
Permalink Reply by Michael Warren on -
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
-
Permalink Reply by Andy Demartini on -
Micheal,
Your explanation clarifies the current auto-takeoff behavior and also explains the other issue we saw, that the airplane would skip the first waypoint. My understanding from reading the wiki was that the throttle would engage only at 3 m/s. This reading incorrect and it is just the heading hold that currently engages at that speed.
I do feel there should be a provision for catapult launch that holds the throttle at "zero" until the "engage" speed is attained. After reading your explanation, that is what we saw but for the wrong reason. We had passed the auto-takeoff step and the throttle came up out of the suppression hold.
Your suggestion to add the speed threshold will work just fine. I'll add this as an issue and would be happy to test it. We normally fly on Tuesdays and Thursdays, weather permitting. Just let me know where to pick up the firmware file.
Andy
PS - OK, I just added this request to the issues list. Thanks again.
-
Permalink Reply by Michael Warren on
-
Hi Andy,
Apologies for the delay. I am waiting on the change to be accepted into the codebase after some small feedback from Tridge. I have been hesitant to make one-off firmware distributions before it gets reviewed and finalised. This is to avoid confusion if anything changed before it went into the codebase (such as the requested change from units of cm/s to m/s) and became part of the 2.70 release.
Michael
-
Permalink Reply by Andy Demartini on
-
Michael,
Thanks or your update. Yes, we are ready to test this new capability and I completely understand the integration and QA required. I will watch for the 2.70 announcement.....
Andy
-
Permalink Reply by george on -
Thanks Michael! That's just what we need. Looking forward to seeing that code update.
- ‹ Previous
- 1
- 2
- Next ›
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
-
Telemetry over cellular …
249 members
-
ArduCopter User Group
1299 members
-
DroneShare Users Group
12 members
-
Andropilot Users Group
183 members
-
ArduPlane User Group
693 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
