Developer

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

Views: 37151

▶ Reply to This

Replies to This Discussion


DeveloperPermalink Reply by R_Lefebvre on January 12, 2012 at 7:38am

Your observations about GPS performance, I've been saying that for a while.  We'll never have a rock solid Loiter based on GPS alone.  It's not possible.  Get a good Garmin hiking GPS (not a road model), and just sit there and watch it.  It wanders too.  That's the nature of GPS.

Now, a good lock should be accurate to within 3m.  I'm not sure if that 3m is a best case, or worst case however.  If you are in your garden, down between houses, it's going to have lower performance than if it's up high with a clear view. 

I don't think altitude control has anything to do with the GPS.  I don't think it uses GPS at all for altitude.

Permalink Reply by Rui Manuel Cravo Marques on January 12, 2012 at 7:48am

I believe civilian GPS systems can't have more than 2.5mts precision if I'm not wrong. Have you thought of an Assisted GPS function like in cell phones, getting position not only from sat but from cell phone transmitter triangulation ? They can be very accurate and give positions also inside buildings.


DeveloperPermalink Reply by R_Lefebvre on January 12, 2012 at 8:59am

Assisted GPS doesn't quite work the way you think.  A-GPS only uses the cell towers to retrieve data on the GPS system to help locate satellites faster than the device could do on it's own.  So this improves Time To First Fix.  I think it also helps accuracy in really bad reception areas.

Most people confuse A-GPS with Cell-Site Triangulation.

In any case, all of this would require a cell phone chip be built into the APM, which isn't likely to happen any time soon.

Now, WAAS is a different system altogether, and is available on many hand held GPS units. I'm curious myself if the Mediatek chip uses WAAS?  Because the 3m claim that I make for hand-held GPS units I believe is assuming WAAS.  Without WAAS, I think it's 10m.

Permalink Reply by Phil Cole on January 12, 2012 at 2:18pm

I am under the impression that WAAS only works in the USA.

WAAS uses geostationary satellites to transmit correction data relayed from fixed ground points in the US monitoring the GPS satellites.

The WAAS satellite footprint covers N and S America only.

http://en.wikipedia.org/wiki/Wide_Area_Augmentation_System

Permalink Reply by Vincent Mees on January 12, 2012 at 2:25pm

In europe we have EGNOS but its compatible with WAAS and vice versa.

Permalink Reply by Rick B on January 12, 2012 at 2:27pm
Permalink Reply by Ken on January 12, 2012 at 3:45pm

MediaTek does have WAAS, it is enabled by default.

Permalink Reply by Rui Manuel Cravo Marques on January 12, 2012 at 6:00pm

Ok, I've been reading about A-GPS and it's like you said, but what about Differential GPS (DGPS) ? Couldn't this be used to achieve higher accuracy ? I believe loiter will alway make some kind of circle. For a good position hold, I guess inertial positioning would be the best. The optical sensor, seems to be a good option for autolanding but not for positioning because of tilt/roll of the quad, unless the sensor would have some kind of vertical stabilization like those for cameras.


DeveloperPermalink Reply by Randy on January 12, 2012 at 6:23pm

Actually the optical flow sensor library includes correction for roll and pitch.  So it uses the roll/pitch value from the IMU and then when it gets the optical flow movement values, it subtracts the amount of motion that it estimates were caused by changes in roll/pitch.

Permalink Reply by Rui Manuel Cravo Marques on January 12, 2012 at 7:16pm

But it has a much more limited range than inertial sensors right ? Like the sonar, it has an effctive range and another con, it needs light to work properlly. The most reliable sensors here remain the gyros and accels :|

 


DeveloperPermalink Reply by R_Lefebvre on January 12, 2012 at 7:34pm

I haven't used Randy's Opflow, but I did use one on a Flymentor and found it to be severely limited in some situations.  On snow, it was useless.  Didn't work well on uniform grass or concrete either.  It needed contrast.


DeveloperPermalink Reply by R_Lefebvre on January 12, 2012 at 6:48pm

And actually, every time I see a really well setup quad video like the one Marco posted, I am amazed at how well the GPS really works.  I think it might drift slowly over time due to GPS.  But it's *stable* in the air.

Unless maybe it's something peculiar to the GPS signal where the people with problems are loitering.  Marco was in a quite clear area.

I dunno.

RSS

Social Networking

Top Content 

1 APM Project vs DJI NAZA and WOOKONG

APM Project vs DJI NAZA and WOOKONG
2 APM 2.5 with NEO-6M ublox gps (not 3DR LEA-6)

APM 2.5 with NEO-6M ublox gps (not 3DR LEA-6)
3 APM Copter 2.9.1.b has been released

APM Copter 2.9.1.b has been released
4 Flying 3D Spline Curves between Waypoints with ArduCopter 3.0

Flying 3D Spline Curves between Waypoints with ArduCopter 3.0
5 Drone shot down by police

Drone shot down by police
6 MAAT final version is being tested

MAAT final version is being tested
7 10k autonomous flight - telemetry guided flight, and other APM tests!

10k autonomous flight - telemetry guided flight, and other APM tests!
8 Help Tuning Arduplane 2.73 With A Large Slow Airframe

Help Tuning Arduplane 2.73 With A Large Slow Airframe
9 Thirty Days (#28): McMaster-116 lift

Thirty Days (#28): McMaster-116 lift
10 Getting ready for Arducopter 3.0

Getting ready for Arducopter 3.0

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

Advertisement

© 2013   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service