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 Bill Jowitt on -
OK, fair enough. The penalty I pay for being an early adopter!
One of the reasons that I bought an APM1 board is that I was having real problems with it crashing for no apparent reason. I thought that it might be an IC2 issue. I now suspect that it was a sub-standard R/C setup. Would your advice be that I should try the APM 1 board until the APM2 issues are sorted in the code and appropriate PIDs generated etc.? As it happens, I have made progress with r10 and am now getting a pretty reasonable loiter performance, but if I can get the same, plus the camera stabilisation back, with the APM 1 board, then it might be worth it.
Regards, Bill
-
DeveloperPermalink Reply by Marco Robustini on -
Angel, loiter work properly here with "I" term from the default "0,1" to "0.020", otherwise starts making circles as always.
I look forward to your tests and those of JL.
Cheers
-
Permalink Reply by afernan on -
Thanks. I´ll test this afternoon. I´ll use your recomendation for "I-term".
Angel
-
DeveloperPermalink Reply by R_Lefebvre on -
I did a methodical test in my basement to track down the source of the sonar noise. It does NOT appear to be electrical. (And just to clarify for everybody, I have the RC filter, shielded wire and heat on my sonar already, and when I flew last the log show absolutely terrible noise on my sonar. This is on a big trad-heli.)
So, first I ran the APM, and only the APM. Xbee, and GPS were on. Servo switching BEC was off. Did a test in my basement holding the heli with the tail vertical so I could shoot the sonar beam down the basement to get a reading that was long, then swung it down to shoot the floor, back up to shoot long, etc. a couple times.Sonar was clean.Then I turned on the servo BEC and servos.Clean.Then I pulled the motor pinion and tried it with the ESC plugged in and the motor turning free.Clean.So, I put the pinion back in. Removed the tail blades and the upper section of the head. So all the gears, the tail shaft and grip, and main shaft were all spinning. There was very little vibration like this. Very little load on the motor/esc also.Clean. Nothing. Check out the attached graph.At this point, I figure it has to be either accoustic or vibrational, as I originally thought. The only potential for electrical noise at this point is possible if the load of the main blades causes the amps to spike up enough to make more EMF? And BTW, it would HAVE to be EMF, as the motor battery and ESC are COMPLETELY seperate from the APM, the ESC is opto isolated in fact.I'll run a quick test again with my cap bank plugged in. It wasn't. I guess there's a small chance the large bank is inductively picking up EMF from the motor. I've heard that's a problem with cap banks.If it turns out to be accoustic or vibration, I think this could be significant in proving that some people who persistently have problems with alt_hold, is because their vibes are too heavy. - Attachments:
-
-
Sonar_quiet_1.JPG, 27 KB
-
-
Permalink Reply by afernan on
-
I have another source clearly identified (for me): the XBee.
If I put it, the sonar goes crazy. If not installed: OK. I´ve repeated this many times and is clear for me.
It also depends a lot in the position of the XBee Tx with respect to the sonar. There are some places that are more or less OK (not related with the distance, but wit the relative position itself).
But I think the noise in sonar is not only one single cause, but many. We could list (at least):
- ESC> reduced with: cable shielding, cable length, RC filter, etc
- temperature and humidity > heating
- Vibration > mounting bracket stiffness
- noise > unaviodable
- XBee > relative position between both
- and maybe some other.
So, in view of the large list, the best solution is to avoid sonar (like in APM2)
Angel
-
3D RoboticsPermalink Reply by Chris Anderson on -
Yes, Xbees can really mess with sonar, depending on how they're placed. Keep them as far away from each other as possible. Once you move to APM 2 you'll probably drop the sonar entirely, although I admit that it is fun for terrain following.
-
Permalink Reply by Vincent Mees on -
At the moment I don't have xbee installed. So thats not the source of my sonar spiking.
When I hold the quad in the air, motors armes but not turning the height is indicated very smooth in the logs.
The beginning of the spiking started as of version 2.56 and up. Then I installed heating and shield and now filter. I can't understand that the sonar use to be rock solid concerning AH.
-
Permalink Reply by Martin Szymanski on
-
I few around some today and the sonar worked like past builds. However every time the rate x and y asked to move it. The copter still wiggles.
-
Permalink Reply by Sylvain on -
I think most of the time sonar noise is du to electrical noise on the 5V. I use 2 solutions to remove the noise nearly completely:
- power the sonar directly from a UBEC module
- in ModeFilter.h make the filter size 2 or 3 time bigger (the sonar response is slower, but free from noise)
But I admit I have no Xbee module.
-
Permalink Reply by Arnt-Inge Hansen on -
If you use current/volt sensor it generate lots of noise. If you unplug the snsor from apm you can see the noise disappear
-
Permalink Reply by Vincent Mees on
-
I have no Amp/V sensor but I will try to put the sonar on a complete seperate power supply.
-
Permalink Reply by Arnt-Inge Hansen on
-
yes separate bec for the sonar helps a lot, you can also try ferrite on wire from bec to sonar
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
-
Turkish Ardu Group
7 members
-
ArduCopter Italian Group
87 members
-
Agricultural UAVs
131 members
-
Melbourne
47 members
-
Documentation Editors
51 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
