Arducopter 2.1 release

Ardupilot 2.1 is out and can be downloaded by the mission planner (or with Git). You must have the latest version of MP to be compatible. If you're compiling with Arduino, you must use the "mrelax" version of Arduino that is in our downloads section. This is because Arduino was never tested with code larger than 128K. And since our code is probably the most complex Arduino project ever, we found the issue. This altered version of Arduino allows you to specify a special compiler flag that makes it work again. Otherwise it's functionally identical to version 22. When we transition to 1.0 of Arduino, you won't need to use a modified version, since they have patched it for us.

This version has a few new features, but is mostly a bug fixes and compatibility with APM2. The nav routines have been updated and well tested. I'm getting very reliable results now.

One new feature that I snuck in was SuperSimple mode, which re-calibrates simple mode when you are flying with GPS > 20m from home. It allows you to fly in any direction in Simple outside of this radius. Check the wiki for more info.

Added Auto_land mode to help with Failsafe implementations.

Here's a video I took flying WPs using CH 7 to toggle record them. I flew back and forth over the park to se how straight a line I could maintain and how repeatable it was, then I recorded a few waypoints to the left and right, then I recorded a landing wp by toggling CH7 when the copter was on the ground. The landing could be improved, it was trying to maintain a location and didn't level out in the last meter to the ground as it should. I was missing the screw holding my Arm in place so it folded in just a bit, no real damage done. BTW, this video is W/O a sonar.

The next video is of the Loiter control. I improved loiter a bit with a bug fix and the stability patch from the stabilization. Wind was mild. Could be tuned just a little higher.

Here's a video from Dec 17 showing WP recording. The radio was on the ground the entire video. The 3DR frame did not have a sonar on it. The landing was recorded as well.

Upcoming:

Tridge wrote a Geo - fence routine to restrict flight within a certain area for Arduplane. We'll port that over to AC. You'll be able to fly acro inside a safe area and have it go into AP if you loose control!

We need one more pass to finalize the Optical flow integration.

Finalization of the Z Accel code.

Have fun and fly safe,

Jason

Arducopter_2_0_56.zip

A suggestion:

The GPS derives velocity measurments in a completly differnt way than position.

It calculates a three dimensional velocity. Internally almost all GPS generate a Vnorth, Veast and Vup/down.

When a wind gust or other environmental change comes along the change will be seen in the velocity measurement before its seen in position. When I worked on my helicopter I used a proportional (only) position error to target a desired velocity. Then I used all three PID terms to derive a desired roll pitch etc from the measured velocity. This resulted in really stable position hold hovers. The fact that your GPS spits out velocity as course and speed with limited speed resolution may make this hard for you to do, I don't know how hard it is to modify the special GPS firmware, but a version that spit out Veast, Vnorth and Vup/down to as many decimal palces as possible would be nice. The GPS I used for this spit out the V record as three binary floats.

As an additional input my autoland code worked as follows:

Set a target down velocity to 1m/sec or so. Hold the target velocity when it touches down the vertical velocity loop tries to keep descending by reducing throttle/collective/thrust . When it detects that the throttle is at zero it declares that it has landed. This even worked well on a rocket where the hovering throttle varies widely as the wt of the vehicle changes 3 to 1 in flight. See: https://www.youtube.com/watch?v=8UJDxp2gv3o&list=UUZI0BwkiC2Vm9V...

This shows a breif takeoff, hover at 6 ft or so then land cycle, 100% autonomous.

Paul

Replies

Pbreed December 16, 2011 at 6:34am

A suggestion:

The GPS derives velocity measurments in a completly differnt way than position.

It calculates a three dimensional velocity. Internally almost all GPS generate a Vnorth, Veast and Vup/down.

When a wind gust or other environmental change comes along the change will be seen in the velocity measurement before its seen in position. When I worked on my helicopter I used a proportional (only) position error to target a desired velocity. Then I used all three PID terms to derive a desired roll pitch etc from the measured velocity. This resulted in really stable position hold hovers. The fact that your GPS spits out velocity as course and speed with limited speed resolution may make this hard for you to do, I don't know how hard it is to modify the special GPS firmware, but a version that spit out Veast, Vnorth and Vup/down to as many decimal palces as possible would be nice. The GPS I used for this spit out the V record as three binary floats.

As an additional input my autoland code worked as follows:

Set a target down velocity to 1m/sec or so. Hold the target velocity when it touches down the vertical velocity loop tries to keep descending by reducing throttle/collective/thrust . When it detects that the throttle is at zero it declares that it has landed. This even worked well on a rocket where the hovering throttle varies widely as the wt of the vehicle changes 3 to 1 in flight. See: https://www.youtube.com/watch?v=8UJDxp2gv3o&list=UUZI0BwkiC2Vm9V...

This shows a breif takeoff, hover at 6 ft or so then land cycle, 100% autonomous.

Paul
afernan December 16, 2011 at 6:25am

PID calculation in the library: the "I" term effect

Reviewing the way the integral component is defined in the library (either APM_PID or APM_PI) I think that maybe it´s not fully correct (or I didn´t understood well the code)

As you know, the integral "I" term in a PID controller is the sum of the instantaneous error over time (the duration of the error) and gives the accumulated offset that should have been corrected previously. The accumulated error is then multiplied by the integral gain ( $K i$ ) and added to the controller output.

The integral term in fact is the "area" below the curve e(t) along time and is given by

$I_{\mathrm{out}}=K_{i}\int_{0}^{t}{e(\tau)}\,{d\tau}$

The way it´s computed in AC2 code is:

_integrator += (error * _ki) * scaler * delta_time;

This is called in every control loop, so no acumulation along time is done. It´s a kind of e(t) * constant, so another "p" term (much smaller)

int x_iterm = g.pi_loiter_lon.get_i(x_error, dTnav);

In fact this is the small "area" below e(t) but only width to the integration step time (delta_time) that is a very small number. This should consider instead a larger period of time (maybe not two much, since this effect is acumulative and could overshoot easily). I think this is why I term doesn´t change things in the present code.

I don´t deeply understand the code, so sorry if I miss something.

Angel
Gordon December 15, 2011 at 2:20pm

Jason - Re: sensing landing

Most full size aircraft (not little Cessnas) have 1 or more switches on the oleo struts known as a "weight on wheels" (wow) switch. As the plane settles on landing the strut compresses and either makes or breaks the wow switch. This signal is used to trigger many events, eg. disable radar transmit so as not to fry ground personnel with microwave energy.

If there is a free input, perhaps a microswitch with an extended arm could be used in auto to shut down the motors. Maybe a looped zip tie to operate the switch so nothing digs into the ground. I hope you find this useful, unless of course it has already been thought of.
William Collins December 15, 2011 at 7:01am

Can you contact me, I am intererested in a custom application.

william@eyecandyinc.com
Rob_Lefebvre December 15, 2011 at 4:57am

This announcement about 2.1 is interesting and I'm anxious to try it. But does it also fix the I2C problem? The program really shouldn't be out of "beta" until this known, serious problem is fixed. I'm still afraid to try loiter until it is.
Farooq Niaz December 15, 2011 at 4:47am

Can anyone tell what is the difference when I use small dia prop vs larger dia props while climbing for maximum altitude. Motors and current consumption is not an issue.
Denny Rowland December 14, 2011 at 4:21am

Clearly this code is optimized to work along side the DIYDrones quad. But of course there will be many who will want to use their own designs. The difference that will be seen in the PID setting parameters is mostly a function of the Motor, ESC, and frame width and the prop. being the most crucial factor. The response that is seen from whatever PID setting will be mostly effected by the weight and efficiency of the prop. Whereas lift efficiency is allied to swept area it does not follow that a large dia. fine pitch prop will deliver the most stable flight dynamics. Motor response/stability is a key factor which improves with the arm being shorter and the rotational inertia being as low as possible. As the heavy lift concept seems to run into large frames and props upwards of 14 " there has been a tendency to loose stability in windy conditions at the same time. Hence these Autoclaved 11x4 carbon prepreg props that have been developed to work with the Tiger Motor 4008 660Kv.As a fast response solution. They weigh just 14 grams. It has thus far been what I would say is a definite step in right direction for anyone wanting to lift a little more weight. Seen alongside a 11x4.5 APC
Jahn Otto Andersen December 14, 2011 at 4:08am

Is 2.1 the recommended version to use if we want the most stable and reliable code? I have APM1.
DaveyWaveyBunsenBurner December 14, 2011 at 12:32am

Jason,

Have you reflashed your ESC code or are they standard?

D
3D Robotics

Alan Sanchez December 13, 2011 at 11:59pm

Loiter is phenomenal. We tested it this afternoon and it was glued to one spot. Thanks Jason!

of 11

This reply was deleted.

Discussions

Arducopter 2.1 release

Replies

Activity