ArduPlane home page

Jeff Zika July 16, 2012 at 1:29pm

Ok here is a weird one. On long tracks between waypoints greater than 64km apart, approx every 5 minutes the autopilot goes offline resulting in a hard dive, random roll, and throttle to idle. It recovers in 1-2 seconds, stabilizes the aircraft, and continues on course. Why?

Also, is there any way to raise the limit of 127 for loiter radius and waypoint detection radius. At 65m/s with 45 deg bank maximum turn rate the minimum radius is 450m. This is way above the maximum setting of 127.

Also, is there any way to add a divide factor based on air (or ground) speed to the roll and pitch PIDs, particularly P? Settings that work at 50m/s are to sensitive at 100m/s, etc.

thanks

Jonathan Challinger July 11, 2012 at 12:38am

Comments on comments on comments:

1. This is why we need better roll and pitch controllers, but additionally you probably need to build in a feedforward from landing gear extension to pitch.

6. There currently is no settings that will make this work. It is part of the controller design. This is something that I am personally trying to dig into and fix.

8. In order to do this, we need an on-board wind estimate that is reliable and stable. We should be able to implement Bill Premerlani's wind estimation soon, which allows us to get true airspeed and wind without using an airspeed sensor.

Jeff Zika July 10, 2012 at 11:45pm

Thank you for all the quick responses...

Like I said, I am evaluating several different systems APM just being one of them. The open source model is preferred so we have access to the source code for changes, at least at this point.

Comments on comments:

1. PID reaction does not react fast enough to handle the trim changes required. For example, landing gear extension results in a strong pitch down motion, and generally at low altitude. By the time it is compensated for, the aircraft crashes. When the gear is retracted, opposite occurs resulting in an uncommanded 2-3000ft climb. Any settings that compensate for this are two sensitive for maintaining level flight...Also, as fuel burns off trim changes which is not compensated for. What I need is for the trim settings to be updated periodically based on flight parameters. My main concern here is when the aircraft picks up the target tow there is a massive increase in weight, drag, and a strong pitch up moment. These need to be compensated for. I am working on a customization of xPlane to simulate the tow and cat launch.

2. Might be a factor of the aircraft speed when it crosses the waypoint. Cruise speed on this is 80m/s.

5. Need to have a way from the GCS to flush the APM waypoint memory that works.

6. So what settings are required to get this working? Need to maintain constant airspeed at all pitch angles.

7. Understood. Will try.

8. What I was getting at is why not use the calculated wind speed and direction, derived from heading required to hold course and airspeed required to hold track speed (over ground) recursively to calculate heading and airspeed required to track course and maintain speed? This is how airborne GPSs do these calculations.

10. Understood. reason for looking at opensource.

11. Will try tuning yaw for takeoff and see what happens in flight. Note that in operation all takeoffs will be catapult so this shouldn't be as great an issue.

Thanks again.

jz

Jonathan Challinger July 10, 2012 at 8:42pm

I deleted my previous posts, but just note that Chris' post was in response to one of mine.

Jonathan Challinger July 10, 2012 at 8:41pm

Fixed:

1. On trim, trim is done by integrators on our roll and pitch controllers. Read up on how PID controllers work.
Tuned correctly, the integrators will integrate out any change in trim.
I have vastly improved roll and pitch controllers in my personal branches. I am hoping to get it released but it is a drastic change and there will be lots of people who don't want to retune. This issue needs to be resolved before it can be released.

2. I often do a one-dimensional circuit with a 180 degree turn at either end and I have never seen this happen.

3. Unsure what would cause that, never seen it happen.

4. Not sure on airspeed. Very fast, I would imagine. Probably limited by the airspeed sensor. Altitude is limited by the specs of the barometer - 30,000ft I believe.

5. Never had trouble with this but there may well be bad bugs there. Perhaps this and 3 point to the user having bad hardware?

6. This is the result of throttle being controlled by unconstrained total energy. If you have too much potential energy (altitude), it will never turn the throttle on for any amount of airspeed error, instead relying on the airspeed controller to pitch the plane down until it reaches the desired airspeed. If this isn't achievable, then it will just pitch to the max pitch (assuming you have an integrator on airspeed.)

7. I believe the same controllers are used. The user's crosstrack gain is probably tuned too high. Note that track following is very poorly done, especially with a compass.

8. The mission planner shows these in the status tab. They are calculated on the ground station as far as I know. Wind estimation is something I am going to be working on soon enough.

9. Agree.

11. There are mavlink commands/waypoints to activate a relay, etc. You can write some code to do it conditionally, as well.

10 & 12. Takeoff command is NOT for rolling takeoffs. I learned this the hard way. This is, so far, intended for hand launches only. Gear extension: See #11 If you have trouble with torque, I recommend tuning the yaw integrator. P puts too much noise on the servo, but a (fairly large) integrator works beautifully. I use 5.0 in the simulator, and 2.0 on my plane. This will also tighten up navigation slightly, as the rudder feed-forward gain will typically apply *opposite rudder* during a turn. The reason it does this is most planes require opposite aileron to hold a bank angle. The solution is a yaw integrator, which will hold a coordinated turn and apply right rudder in reaction to the torque.
We could work up a feedforward gain for throttle and pitch to rudder, but someone would have to research the math on calculating P-factor torque. This would be very secondary to getting good roll and pitch controllers going, which I have working at the moment, but we need to work out a way to get them released without messing up anyone's currently-working gains.

3D Robotics

Chris Anderson July 10, 2012 at 8:32pm

Sorry, I renumbered the items when I posted to the list, skipping the ones that weren't issues. I hope you can figure it out from the responses.

Uwe Gartmann July 10, 2012 at 3:57pm

Hi Jeff

Do you think the APM v1 / v2 is the right solution for you? You are running a quite dangerous airplane. Your list of issues looks like a product specification that is find by professional aircraft manufacturers or military companies. Please understand me right. The APM platform is a cool hardware / software package for experimental usage. But for such a heavy and big airplane its is the wrong solution with the contributed software. I have an APM1 version here at home. Now unsued for several month because of huge complexity of the project and several iconstistence in the software. Please get a professional equipment for your and our safety. Not to forget, APM is open source, so you can extend the functionaltity of this product any way you like.

Jeff Zika July 10, 2012 at 11:41am

Ok, this is the first post to Arduplane group so please bear with me.

We are evaluating and testing autopilots for a high speed target drone, as in 200knot + and up to 10000ft alt. I have been working with an APM1 running Arduplane 2.4 in HIL mode with xPlane. These are some of the comments / concerns so far.

1. Trim is a real pain in the ass. The aircraft trim changes dramatically during flight due to configuration changes, pickup of towed target, dropping target, gear retraction or extension, etc. Is there any way to automate the trim changes? As it is now, every time trim changes are required it has to be done either in manual mode and switch back to auto, or manually using parameter changes through telemetry.

2. The autopilot appears to command a switch to loiter or circle after waypoint passage if the angle between programmed tracks is greater the 90deg. This behavior is quite consistent.

3. One programmed flight to 5000m completely corrupted the APM settings in such a way that switching out of manual commanded a full power dive in all auto modes.

4. What is the maximum airspeed and altitude. The aircraft we are testing is capable of far in excess of 100m/s cruise speeds and climbs at over 7000ft per minute. (yes, it is prop!)

5. Waypoints don't seem to be written consistently. Saving waypoints to the APM some times (most times) does not overwrite existing waypoints or remove any in excess. This can be quite confusing since the aircraft takesoff in some apparent random direction that does not match the programmed route. Reading the waypoints shows the errors. This is a pretty major bug that needs to be addressed.

6. During any auto mode, descents drop the throttle to idle but keeps the decent angle consistent (as it should) thus resulting in a drop in airspeed. The throttle should be managed to maintain a constant airspeed irregardless of climb or decent angle, within the capabilities of the aircraft of course. FWIW, the throttle increases to cruise setting with speed increase once the decent and level off is completed.

7. Tracking a path between waypoints results in a snaking flight path. Tracking direct to a waypoint does not. Can't the same code be used for both?

8. Where is current wind speed and direction as derived from GPS groundtrack vs. heading available on the GCS?

9. Need to be able to specify loiter and circle direction as a parameter of a loiter waypoint.

10. Is there any way to command landing gear retraction after successful takeoff and extension after passing last waypoint before a landing waypoint?

11. The drone we are testing will use parachute recover and catapult launches. Is there anyway to set a waypoint to deploy the parachute.

12. There needs to be a way to ramp up the throttle slowly on takeoff. Full throttle at low speed results in a hard turn to the left which is NOT corrected by the APM. Normal takeoffs with this aircraft are nearly impossible because of this (prop is 24x24 4 blade... i.e. LOTS of torque)

The waypoint programming issue and autotrim (from flight data, not from RC settings) are really must haves for this to work for us. Any ideas if these can be added / fixed?

Best Regards

JZ

Gavin Yeo July 9, 2012 at 11:37am

is there a really easy step by step guide to install quadcopter firmware to ArduPilotMegaV1 128k version.??? I am helping out a fellow flyer find a solution for this board but it says 'Firmware is too big for 1280 please upgrade harware'. Any links I can send to him to tackle? The easiest option is best - thanks. Or will the Mission Planner be updated soon to take care of the older APM V1's with 128k. I hope so!!

An expensive paper weight if he is not able to upload firmware anymore.

Justin Boland July 3, 2012 at 9:15pm

In case anyone else has Lisa's and my problem, it has been shown that too high a voltage on the APM will cause exactly this problem. That thread is here: Xbee no GPS