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:
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.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
Replies to This Discussion
-
Permalink Reply by Rui Manuel Cravo Marques on -
Sure, there is hdop to take into account too besides the number of sats in line of sight. http://en.wikipedia.org/wiki/Dilution_of_precision_(GPS)
-
DeveloperPermalink Reply by R_Lefebvre on -
Good stuff.
I wonder if, when my GPS says 3m precision, is it taking into account HDOP, or is it simply assuming it's 3m because it has X number of satellites?
In any case, this just reinforces the potential for error when flying in your garden surrounded by houses. And it doesn't even take into account multi-path reflections off the houses.
-
Permalink Reply by Arnt-Inge Hansen on -
I am 100% agree with you. The observations I made with my new DJI Hexa agrees well with what you say. When I hover without gps the copteret is more stable than with GPS. With GPS the copter begins to drift like observed on a garmin gps. My suggestion is to forget the GPS, get the apm as stable as possible with the gyro and accelometer, then add gps on it all afterwards.
-
Permalink Reply by Bill Jowitt on -
Any ideas to explain the observed performance of loiter, i.e. that after a period the drone seems to wander off? At the moment I would be delighted with 5m accuracy.
What I am suggesting is that the GPS be used at least as a backup. If you take the horizontal position when the loiter is invoked and draw a circle representing the accuracy of the GPS, you know that the drone is somewhere inside that circle. If at a later stage you take another GPS reading, draw another circle and there is no intersection, then you know that the drone has definitively moved away from the original loiter position and you can at least have the drone move back to the original GPS coord. At the moment, the drone does not behave like that. After a while, it starts moving away and carries on moving away, rendering the loiter ineffective.
-
DeveloperPermalink Reply by R_Lefebvre on -
I want to take a look at your logs before I comment on that. One of the clues is, what the the lat/long errors within the program? If the code knows that it has a large error, then something is wrong, maybe PID tuning or something. If the data logs show lat/long errors in loiter that are close to zero, then it's obvious that the code is just following the GPS signal around, it doesn't know any better.
-
Permalink Reply by Bill Jowitt on
-
Robert,
Log 10 attached, which was the flight I described in my post 3 hours ago above. Delighted if you can analyze it - I have just been looking at the results in Google Earth, .kmz posted above, the last loiter segment in that, 8 Flight Path LOITER best shows the hold then wander behaviour I am trying to describe. Was using the PIDs installed on upload as I presume those are the recommended values at the moment. Just flown r10, comments to follow.
Thanks, Bill
- Attachments:
-
-
2012-01-12 12-29 10.log, 829 KB
-
-
DeveloperPermalink Reply by R_Lefebvre on -
If the wandering shows up on the .kmz trace, then it was not following the GPS around. If it is was just following an errant GPS signal, then it would look like it was stationary in Google Earth.
Unless... the GPS signal was moving around so fast the copter couldn't keep up, but I'm not really sure that's possible. When it wanders, it's usually pretty slow. At least from what I've seen.
I don't think it's a safe assumption at all to use whatever PI values come in when you download. Who knows where they came from?
What you guys need to be doing is keeping track of what PI values work well with what setup, and what code. And it's not just the frame, but motors and props make a difference too!
-
Permalink Reply by Bill Jowitt on
-
Robert, the .kmz trace reflects what I remember of the flights, so I think the trace shows the behaviour of the drone well enough to illustrate my concern that the loiter functionality in r9 at least seems to work for a while and then lose it. From the static test, it does not look to me as if there is any GPS wandering...
Regarding PID values, I would be delighted if people promulgated what worked for them. JLN is very good at showing what he uses, but it is for his custom frame - I tried them once on my 3DR and it scared the hell out of me. If anybody else is using a stock 3DR with an APM 2 board and is getting good results for loiter, whether in still air or wind, I would be delighted to see their PID settings. It would be useful also to get guidance from the developers, especially if they would like to see different PIDs tested in the real world. It appears to me that there is a substantial difference between 2.1.0 Alpha and these 2.1.1 releases and that the strategies for the Loiter PID settings are quite different. I would be a good test volunteer as I have as stock a 3DR as it is possible to get, especially for testing the APM 2.0 board (JDrones A-2830/12 850KV motors, 10x4.5 EPP props). I do have a camera mount (although I have removed the camera until the stabilisation works) and the only other mods I have made is to put ping pong balls on the feet of the legs to reduce tipping, and a ping pong ball on a carbon fibre rod taped to the top stack to indicate orientation.
-
DeveloperPermalink Reply by R_Lefebvre on -
Ok, I'm looking at it now and notice something strange.
If I look at Lat and Long from the GPS lines, the numbers looks strange to me. Maybe it's just wherever you are located I'm not familiar with those numbers. Not sure.
The Waypoint distance lines seem to show that the system knew it was not on target.
Unfortunately the data I really wanted to see is not there. I wanted to see the Nav P and I values. Neither is a record of your mode switching. It's also weird that there is data in column without headings.
But here's something really strange: Look at Nav Roll and Nav Pitch. Nav Roll sometimes is zero, and sometimes has values. I assume it's when you were in Loiter. But Nav Pitch is always zero. Either something is wrong with your logs, or your quad for some reason never had Nav Pitch trying to move it on target?
-
-
Permalink Reply by Bill Jowitt on
-
Robert, here is the .tlog file from Mission Planner that relates to that flight, just in case it can shed more light on what is happening. Is there any chance that my configuration or PID settings could be causing this, or is it a code problem?
This may have been overtaken by events as the behaviour of loiter seems to be different in r10 - in wind, the drone goes in big circles, in no wind loiter is excellent.
- Attachments:
-
-
2012-01-12 06-57-18.tlog, 1.1 MB
-
-
-
Permalink Reply by Rick B on -
Isn't that why it's called "LOITER" and not "POSITION HOLD"?
With GPS, you will always "wander" around a point, I think that's what the software guys set it up as so that you would loiter 5 meters around a set position.
I think you would need the optical sensor to do a true position hold.
-
DeveloperPermalink Reply by R_Lefebvre on -
I agree. I would like a better inertial hold, but we don't have that yet. GPS can only be so good. I'll be happy if/when they do inertial, but in the meantime, this is what we have.
The big issue that I see is autolanding using GPS is going to be a bit sketchy. If it's wandering around when it touches down, the heli will tip over.
Social Networking
Top Content
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
-
Documentation Editors
51 members
-
ArduRover User Group
184 members
-
ArduCopter User Group
1290 members
-
Swiss Drone Group
11 members
-
Andropilot Users Group
182 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
