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
Replies
Hi,
I'm facing an issue and maybe someone can help me. I'm using the new 2.1 version in my hexacopter and it is drifting always to the same direction, don't mind where the hexa is pointing to.
As I apply stick command in the opposte direction it drifts more and more. When I land and disable and reenable the motors it gets back to normal and then the drifting process starts again.
I have my filters pads soldered already.
Any clue?
Thanks,
Leonardo
Hi,
wanted to try 2.1, but I'm get he "Sketch too big" error, as I have the 1280 and the sketch size compiled is 127952 .
I've tried with the version in Git, and the one posted in this thread.
I've also disabled the login " #define LOGGING_ENABLED DISABLED" in the APM_config.h
Any ideas??
Dani
Jason, When are you upload 2.1 in wiki Arducopter. I want upload to my board from arduino.
For users with "no standard hardware" and without GIT, or just if you want see the code, i upload the 2.1 Alpha here.
It's "untouched" GIT" release of today.
ArduCopter_2.1.0_Alpha.zip
Very Cool!! I am anxious to test!
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
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.
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.
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
Is 2.1 the recommended version to use if we want the most stable and reliable code? I have APM1.
-
3
-
4
-
5
-
6
-
7
of 7 Next