Arducopter 2.1.1 alpha

This is a work in progress. I've tried to address some fine tuning and performance issues.

Denny R. had made a comment about the inertia of bigger props causing issues. I've added a low pass filter to smooth the positive acceleration of the props to see if we can get at this issue. It may require tuning up Rate_P for a few folks, but I saw little issue in multiple flights.

Crosstrack had a small math error that decreased the resolution of it. I've fixed that and upped the default gains to get better tracking.

Made WP hit radius 1 by default. even 3m is too much for quads. (If you pass a WP you will move on to the next)

The Loiter method is tuned a little better by default, and now uses GPS offsets when flying less than 1.5m/s. Code experimentation will continue on this front. Thanks to Emile and afernan for their help!

A fix in the Z Accel startup was added to get an averaged result.

Added the ability to enter Loiter with Optflow enabled. - still a work in progress, not for everyday use just yet.

This alpha is on GIT now and is for user's who want to test code. As always, you need to use the "relaxpatch" version of Arduino you can find in the downloads section.

Update: We've found and patched some small type bugs in the latest and updated some GPS drivers in the Library. Be sure to pull the latest code and check http://apm.tridgell.net/ for the status of each build run against the SIL sim server.

Update r3:

I pushed a version on to GIT that addresses a number of issues.

- the low speed GPS XY calculations were incorrect and have been fixed

- Nav_Rate I term has been removed in loiter control - it's too easy to get two iterms working out of phase

- A second derivative has been added to Roll and Pitch. I found it removed wobbles nicely - Can be adjusted in the planner as STAB_D with a default of .25 (just enough)

- Smoothing has been applied to the motor commands in a way that really quiets down the alt hold pulsing without much effect on latency

- Yaw now has a dynamic constraint and I've upped the yaw gain.

- The motors output now have an LP filter on them so that the accelerate just a tad slower than the deceleration. This is a test to see if it helps big Octo's and Hexa's

- The Rate_I term is now zero'd for first five seconds after takeoff to keep balance.

- Loiter gains are lightened up a bit

- Nav_Rate_P is lower to remove back and forth sped related hunting in loiter

- Compass is enabled by default

- New I2C Library now included which should solve I2C related lockouts

- optflow is still a work in progress.

Update R4:

This update is based on flights today in a very windy environment.

It occurred to me that we're handling the WP nav I terms incorrectly and I reworked the WP navigation to share the same I terms from the Loiter. Even though they use different error input, etc, they turn out to both deal with wind in the same way. I have not Flown WPs with this new code, but heavily tested it in the sim and It's really rocking in hard wind. Transitions from Loiter flight and Nav flight are very smooth. Please let me know if you have luck.

Update R5:

This is a quick patch based on a bad crash Marco had. My theory was an I term that built up during wind that needed to be reset, but wasn't. It's a corner case but It bit Marco pretty bad. Please re-pull if you have R4 running to go to R5. And please, please be careful. This is alpha code not for general testing, but for development. Don't fly it on anything you would feel bad about crashing.

Jason

Update R6:

Includes fix for Acro mode reset bug.

I went through all of the global variables and gave them lengthy descriptions. It's worth a read if you want to learn more how the internals work. I'll be doing some more organization like this as we move forward with an architectural redesign for 3.0 \

This version is mostly clean-up, but does include 1 interesting performance enhancement. It's disabled by default because It's fairly untested. The idea is that the wind compensation created by the Iterms for lat and lon in Loiter and Navigation are carried over into Stabilize. This unifies all of the modes so that when you switch modes, you don't get a small, but fast change in pitch or roll. This is only noticeable in high wind environment.

To get this to work, I look for near zero velocity and start moving the pitch and roll into the wind control items. This takes a transformation from copter frame to world frame, but the result is the copter will hold the position against the wind with the sticks in the center of the controller. If you fly around the wind compensation will bleed off slowly - about 30 seconds.

Again, this is off by default and needs significant testing, preferably in the HIL sim first.JNL has already started and flown this version for real.

The feature may be off by default for another version or two, but just letting you know it's there.

I think it will go a long way to making the mode changes feel seamless.

Update R7:

Added an auto-land timer for RTL. If you don't change modes for 20s after the copter arrives at home, it will begin to auto-land. If you have failsafe and no GPS, you will immediately begin auto-landing.

Failsafe RTL now goes 10M up as it RTLs to avoid obstructions.

Added SIL test for failsafe.

Update R8:

Minor tweaks and cleanup

Update R9:

Made climb rate controller for landing universal for all altitude changes

Update R10:

Updated Loiter controller - Works great in the sim, thanks Afernan.

Thanks,

Jason

I think my contribution to the progress of the code dev. is very limited as there are some people here who are so far ahead of my understanding that it is pointless to even try. What I can offer is some info as to what the direction of future multirotor stabilization might be headed. We know that the ESC's pwm refresh rate is quite an important factor in dealing with the effects of wind turbulence. But more powerful is the way in which the motor is matched to the ESC. Quite dramatic effects can be seen with the timing settings. I recently had a motor shut down in mid flight due to the low timing setting of the ESC not being optimized for the low 600 Kv. motor. It needed a high setting to work efficiently. My work has centered around the motor prop. combination and some quite interesting facts have emerged. To sum up in a few words I would say that the larger the distance between the motors the further the pid settings stray from the ideal. The larger the prop. and the heavier the prop. then the worse things get. Low Kv. motors produce a faster response if matched to the ideal pitch angle. Importantly the dia. should be matched to the payload as it is important to keep the RPM's high in the descent. i.e. keep it as small as is required to make an efficient lift. I have come to use prop. dia. as an effective means to buffer the effects of turbulence. Just my 2 cents worth. The props. that I have developed for this task are 11x4 and weigh only 14 grams. they are very thin and are autoclaved in carbon prepreg. they are designed so that they can be cut down to match the weight of the model. I looked at insect technology to derive the section and surface finish in a world where reynolds numbers are meaningless.

Replies

Developer

Jean-Louis Naudin January 3, 2012 at 12:16pm
Developer

Marco Robustini January 3, 2012 at 12:55am

Hello everyone! One very important thing: do not use absolutely the ACRO mode with this release and with others over 2.0.50 (including), as has already written Jason is there's a remote possibility that it may take over a problem in flight, my heavy octo sacrificed himself for others to test this thing, with a loss of over 1000$ but making it in the future you save a lot, ensuring a more secure future for your.
The incident is luckily documented, logged with telemetry and filmed, that's part of my cooperation with DIY Dev Team, although I would prefer not to happen (LOL).
I waited to alert the community because we wanted to make sure the problem was not an isolated case but now Tridge, with a thorough and surgical analysis he understood what happened, and all we are infinitely grateful.
No other mode of flight is afflicted by this problem, if you do not use ACRO for now you can fly much safely.
This anomaly can not be present if you fly with all the simulator, but just in the reality and for a number of specified steps, although it is quite unlikely but not impossible.
All future releases will be fixed from this bug/issue, Jason clearly write it in the news.

Cheers, Marco
Developer

Jean-Louis Naudin January 2, 2012 at 9:27am

Test of the firmware ArduCopter v2.1.1 R5b in HIL mode on X-Plane v9.70

Regards, Jean-Louis
Gustav Kuhn January 2, 2012 at 7:00am

Just a thought here,,,,,,

With the code getting somewhat big (read, sophisticated/mature), isn't it time to split MultiRotor, Trad Heli and Fixed Wing into their own sub-groups?

With slimmer code, it might be easier to spot shortcomings, for all disciplines.

I'm sure Michael Oborne could easily adapt Mission Planner (my favorite! ), to load/pull/get just that part you require ?

After running r5 on my stock quad today, it seems there is quite some life left in the older boards.....
Ruben Wijnhoven January 2, 2012 at 6:37am

I just tested R5 with medium wind on a apm2 quadcopter. For me r5 is a big no. I have a lot of surging on the engines in stable mode. Copter yaws left and right all by itself. And even rolls sometimes to the left and right. It showed much unpredictable behaviour. I also posted my log. I am not sure but something seems wrong. With 2.1 I get with the same pids I used today I get a lot better result. For me 2.0.49 with apm1 was the best results I ever had with arducopter.

2012-01-02 03-35 5.log
Rana January 1, 2012 at 7:17pm

Marco, can u share ur plugin of the Aero-SIMRC ?
Developer

Jason Short January 1, 2012 at 4:50pm

Some things have come up in testing that really warrant some rigorous testing. I think R5 is OK, but I would be extra careful and I would not fly Acro on it yet. It may be a week or two of testing and reviewing code before we can release the next version.

Jason
Arnt-Inge Hansen January 1, 2012 at 7:01am

Today I am going test my new Hexa DJI wookong, I will compare it with Hexa apm and come up with constructive elements so that one day I can use my 2 x apm1 and 1x apm2 in a stable multicopter. I asked what accelometeret be used to in apm, but has not been answered?
I have seen in multiple feedback here that the stability is preferred overall before a working Loiter. With a stable platform, the rest of the development will go faster and the only limit is your imagination.
Denny Rowland January 1, 2012 at 12:29am

I think my contribution to the progress of the code dev. is very limited as there are some people here who are so far ahead of my understanding that it is pointless to even try. What I can offer is some info as to what the direction of future multirotor stabilization might be headed. We know that the ESC's pwm refresh rate is quite an important factor in dealing with the effects of wind turbulence. But more powerful is the way in which the motor is matched to the ESC. Quite dramatic effects can be seen with the timing settings. I recently had a motor shut down in mid flight due to the low timing setting of the ESC not being optimized for the low 600 Kv. motor. It needed a high setting to work efficiently. My work has centered around the motor prop. combination and some quite interesting facts have emerged. To sum up in a few words I would say that the larger the distance between the motors the further the pid settings stray from the ideal. The larger the prop. and the heavier the prop. then the worse things get. Low Kv. motors produce a faster response if matched to the ideal pitch angle. Importantly the dia. should be matched to the payload as it is important to keep the RPM's high in the descent. i.e. keep it as small as is required to make an efficient lift. I have come to use prop. dia. as an effective means to buffer the effects of turbulence. Just my 2 cents worth. The props. that I have developed for this task are 11x4 and weigh only 14 grams. they are very thin and are autoclaved in carbon prepreg. they are designed so that they can be cut down to match the weight of the model. I looked at insect technology to derive the section and surface finish in a world where reynolds numbers are meaningless.
Developer

Marco Robustini December 31, 2011 at 12:21am

R4 is on GIT, thanks Jason for your hard work about some comparation with a big MK Octo like mine (i think is the same, Droidworks carbon frame)... :P

of 9

This reply was deleted.

Discussions

Arducopter 2.1.1 alpha

Replies

Activity