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 -
I uploaded 2.1.1r10 to test and it looks like it's APM2 by default, can you confirm ? Please mention that if you can. Thanks
-
Permalink Reply by Tomas Soedergren on -
Regarding motor control properties.
On other threads is has been suggested that ESC throttle signal response would affect overall control characteristics significantly. Normal ESC are assumed to apply a low pass filter in their firmware that negatively impacts the APM controllers ability to establish a tight control loop
So, in short, this lowpass filter, normally present in ESC firmware, is undesired for the multirotor usage, and we would benefit from having the option of disabling/reducing the lowpass factor.
Is this correct, or not?
I am asking, since I have started a conversation with the product manager of a major ESC manufacturer on this topic.
Before proceeding further, I would like to have your knowledgeable confirmation that I got it right. :)
-
Permalink Reply by Peter Seddon on -
This thread http://www.rcgroups.com/forums/showthread.php?t=1513678 may be a starting point for what others are doing to rewrite/reflash the firmware in various ESC's to make them more suitable for 'copters (higher pwm frame rates and faster response). The problem they have recently run up against is that the ATMega8 processors used in these ESC's is being replaced by an SiLabs processor.
Peter
-
Permalink Reply by Tomas Soedergren on
-
Yes Peter, I have seen that thread, and as I understand, the main reason of all this reflashing of ESC firmware is to make ESC respond without restrictions of lowpass / smoothening algorithms.
Right?
-
Permalink Reply by Gustav Kuhn on -
Tomas, connect one of "our" speed controllers to one of "our" motors, with one of "our" props.
Connect that to a Rx, and bang the throttle from one end to the other, as fast as you can.
The lag you see, is the inertia of the motor/prop.
The props we use are also way too flexible.
I previously had much stiffer props I sourced from my LHS, grey, grp.
The quad flew much better, and then I went and dinged the pusher prop in front.
And now the LHS can't get these anymore, grr.
-
Permalink Reply by Don Brooks on -
What's that got to do with the development of a new arducopter firmware release???
-
Permalink Reply by Tomas Soedergren on
-
Don,
If (?) you were referring to my posting, then: PID control system loops, in which the ESC response is an inevitable part, seem to bee an ongoing theme of new firmware release, true also in this version. That´s why.
Besides, but not so correct, the latest FW release thread is always the thread gaining the most attention. So if the matter at hand is not totally off topic, it is tempting to make the posting here, in the spotlight.
-
Permalink Reply by Bill Jowitt on -
More observations on flying and testing 2.1.1r9, stock 3DR, APM 2.0 board.
Much stronger winds this morning, so heart in mouth gave it a go. First attempt at Loiter, the drone just wandered off and showed no signs of trying to get back to the start point. Took it up a bit higher and more upwind, improved in that it did go back to the loiter start, but then wandered off again and started losing altitude. Took it even higher, and presumably into even stronger winds and it worked really quite well for a while. Visually it seemed steady and holding position really quite impressively well, but then it started wandering off and descending under its own accord. I was running out of safe battery time, so went to manual. As I was descending from a reasonable height, did not really have enough power on to hold position well and with no faith in RTL after the previous flight, I just got the drone down safely in the next field.
Observations - as per JLN's comments on previous releases, r9 seems to work better in higher winds. However, it seems to lose interest and eventually wanders away. Also, the altitude control is not good. That may be partly my fault, especially on the third loiter segment, as I was applying quite a lot of power to manually hold it in place and went straight to Loiter from Stab. That said, on both working loiter segments, the drone ascended quite a lot, and then in the wander phase started descending, which is alarming. This is a subjective view from looking at Google earth tracks, but it seems to me that the "wander phase" starts by the time that the drone has a track of 75m in each loiter segment, sometimes less, e.g. 45m, but I have not seen a good loiter with over a 75m track.
I then did a test on some suspicions I had. I placed the drone in my garden with a clear view of the sky and left it until it had a good GPS lock, connected Mission Planner and just watched its track. Over the space of a few minutes, the drone apparently wandered up to 6m and descended over 3m into the ground. I played the log back, and I had 7 satellites and the GPS coords did not seem to move at all, but the MP view of what the drone was doing indicates a problem to me. If when the drone is absolutely static, it thinks it is moving in all 3 dimensions, how on earth are we ever going to get a decent Loiter? Maybe that is why it seems to wander after a while, if the drone starts chasing a moving position. Have the Loiter algorithms and the drone's sense of "position" given up on GPS altogether?
So in conclusion - Loiter can be impressive in difficult conditions, but only for a while. Altitude control does not look great. RTL did not work last night, nor does camera stabilisation. There seems to be a problem with the drone's sense of position when compared to the actual and GPS positions.
Data attached, the first is the .kmz file of this morning's flight. The second is the .tlog of the static test (the .kmz goes underground!).
- Attachments:
-
-
2012-01-12 12-29 10.kmz, 61 KB -
2012-01-12 11-08-08.tlog, 583 KB
-
-
Permalink Reply by Gustav Kuhn on
-
Use U-Center, from the uBlox gps guys, and you will see that the most accuracy you can expect in the horizontal plane is about 5 - 10m.
It is substantially worse in the vertical plane.
Accuracy also gets degraded under foilage, and from reflections off buildings, trees, etc.
If you look at the FlyMentor stuff, as fitted to 450 size heli's, Optical Flow is the answer.
-
Permalink Reply by Vincent Mees on -
So again, we shouldn't solely bet on GPS info for loiter .....
-
Permalink Reply by Bill Jowitt on
-
OK, I understand that there is a limit to GPS accuracy in that if we relied solely on GPS, we could only hope for a 5-10m box, but there still looks to be a problem to me. In my static test, the GPS coords did not appear to change, yet the drone "moved", so there is also an accuracy problem inherent in the inertial sensors (and it looks to me like 5-6m over a few minutes). Does anybody know what the accuracy parameters of the APM 2.0 board inertial sensors should be over time? How does that compare to the GPS? Surely at some point, a GPS coord reading should be referred to and if the delta between that and the original loiter position, is greater than the inherent accuracy tolerance of the GPS, the new GPS coord should be taken as a better truth and the drone use that to move towards the original loiter position? At the moment, the loiter seems to lose all reference after a while and simply starts moving further and further away from the original loiter position during real flights.
-
Permalink Reply by Bill Jowitt on
-
I can see that Optical Flow sensors are available and there is some code, but what are people's experience of using it on real flights? I seem to remember seeing some comments that effectively it is still under development.
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
-
ArduCopter User Group
1355 members
-
Andropilot Users Group
203 members
-
Moderators
24 members
-
ArduRover User Group
207 members
-
Japan ArduCopter Group
58 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
