I just pushed Arducopter 2.2 to the Mission planner. This version went through extensive testing by a brave group of flyers and with both HIL and SIL testing.
See this link for more:
http://www.diydrones.com/forum/topics/arducopter-2-1-1-alpha
If you run into any problems please let me know here. If you find a reproducible bug, please add it to the issues list.
tuning tips:
If you run into Loiter issues, try adjusting LOITER_P. It's 2.0 right now which may or may not be to aggressive for your copter. Nav is no longer used in Loiter control, which should make tuning easier.
If you run into a circling issue, try lowering LOITER_I to 0 and see if it goes away. If not, check your compass declination. A negative error will produce CCW rotations, a positive error CW.
If you have issues with alt hold, try lowering your THROTTLE_P, it may be too high for higher thrust copters.
If you have wobbles and can't seem to get rid of them, there is a new term called STAB_D, which is a derivative term used to tune out the wobbles. You can increase it until they stop, but just like driving a cadillac, you loose some performance and handling. In the CLI "tune 16" in setup will let you control this in flight, and "tune" in test menu will let you see the value printed out interactively before flight. See the wiki for more detail.
Many testers gave me a thumbs up on the code, so if you have an issues please post the flash log from the copter. The tLog isn't that much help to me for debugging as it doesn't capture the needed values at high enough rates.
(Remember, if you'd rather pull the code from the repository and load it with Arduino, you must use the "relaxpatch" version of Arduino in our downloads section.)
Update 2.2b2
I believe I found the simple mode error. It was a bug that was working OK until Tridge fixed it so it was declared properly. Then the bug became active. I made the Simple mode function internal variables static and this should fix it hopefully.
I updated alt hold to not use dampener for now until we get more testing. Some folks saw a latency induced oscillation which was pumped up by the D term.
I added the automatic throttle cruise or hold value as a compile time option for testers. This basically looks at your throttle and climb rate while in stabilize or acro and determines your optimal hover value. This means you can enter any autopilot mode and not have to worry about your throttle position. It should make alt hold more reliable if it works. This is off by default until we get good field tests back.
Update pushed to GIT.
Update 2.2b3
Just some refinements. I added JLN's throttle curve mod for landing. Hopefully that's correctly implemented.
Made the landing delay from RTL user settable
removed the ADC gyro filter, I was doing a lot of testing and determined it wasn't worth it.
Enabled the auto-throttle control by default. Please test in the sim
Altitude no longer resets when flying in Loiter mode
Pitch and roll dampening is smoother now. try values up to .08 for very dampened flight.
Mavlink can now trigger auto-land
I'll push a hex when I hear some good news from HIL testers.
Update 2.2b4
Update 2.2b6
OK, 2.2b6 is on GIT. The Mission planner is going to be out of sync until the release code. until then you can use the APM_Config.h or the parameters list in the Mission planner.
STAB_D : This is the gyro accretion dampener. This can remove small wobbles during sharp changes in angle commands. Making this too high can have a negative effect in performance and add a memory effect that can cause temporary loss in control. The in flight tuning is ranged so you are just below that effect.
If you haven't noticed before the control loops are in two stages. The first is a PI stage that converts some sort of position or angle error into a desired rate. These generally do not need to be tuned. They are more of a user preference on how fast you want the copter to perform a motion.
The second stage is the actual PID loop that needs to be tuned for the copter. This converts the desired rate into a motor command of some sort. I added a D term based on Igor's recommendation to the PI's for each rate controller. These should show up soon in the mission planner for the release. I cannot give you a concrete answer for how to tune the D terms, because they each depend on their function such as alt hold or loiter, etc.
Still, the absolute most important term is always the Rate_P term for each loop. Start tuning here.
The default PIDs are in the what flies great for a stock jDrones/3DR Quad with the purple motors in X mode.
Thanks,
Jason
Replies
where we at for hexa code, good to fly?
Paul
I suggest take 2.0.49 ad the ic2 repair. Make it compatible with apm2 and we have a winner. That was the one firmware we all agree upon that was working. Everything later then 2.0.49 has been buggy etc.
to Jason and the dev team:
I've got a fully built hex waiting to be flown. Problem is I don't have trustworthy software to fly it.
It seems that I keep waiting for stable software to be released. But instead the only releases I see are alpha and beta's with added new features which I really don't need.
Would it be possible to release a version (like the 2.0.49 but with the essential things reworked like I2C libraries and stuff) which only had the basic features (like alt hold, loiter and rtl) and which works perfectly without bugs.
Like that people like me could actually fly until a better stable version comes along.
I really don't feel like waiting forever for a stable version or actually trying a non stable version which could end up in injuries or damage.
@Jason @Rui @Marco @Jean Louis @Afternan and all the other that are working on new revision of code
Great Jobs guys. :) I see last upgrade on the simulator and in real world and also see last result with the Hil with last patch doing by Jason
In these week i'm working to finish the porting old revision of library for MP32 to new one . I hope that in 1 week i finish my work. I continue to test last update on simulator and i see that is not yet solve the problem of loiter ... the quand continue to move around and non stop to move.
So I'm testing the opportunity to use our last platform MP32F4 to develop a INS based on gyro , acc and GPS ,too
So i check that in some gps as trimble that i use in last 10 years there are the opportunity to ast to gps the speed of quad on 3 axis x , y and Z ... so i think that this could be an interesting suggestions for develop simple INS .
So is important that the gps have differential correction to obtaing good precision on info about the speed.
What about the experience of other people in the thread ?
What is the better gps for this kind of data ? @Jason @Randy is possible to have some update on MTK to use this kind of data and also the status of differrential correction in realtime ?
I think that MK and DIJ use this kind of info for his INS algorithm .. infact on NAVI of MK there is only magnetometer and gps and the same is for DIJ antenna on it there is only GPS and magnetometer there isn't any kind of acc or gyro.
Best
Roberto
Doesn't anyone like me have tried ß3 from GIT with AeroSim without being able to pull straight on the quad from the ground?
Just to know if there's any real problems in the planner (1.1.26), in the GIT ß3 version or in my mind (LOL), Jason has made many changes from the ß2 and much has changed even in the planner by Michael (about HIL, now you must select the square "quad" for AeroSim).
Maybe in the real flight works fine, but is better not to risk.
Here goes :) blue sky, temp +/- 18ºC, 0km/h wind, perfect conditions, 1600gr quad (with electronics + battery), 12x3.8 props, emax 2218-11 930kv motors, firmware 2.2b2xp2, modes LOITER, RTL and AUTO in action. My PID settings :
Flight Video :
Flight path : desired vs real
2012-01-21 02-42 2.kmz
2012-01-21 02-42 2.log
Hi,
I flew 2.2b2 today, it was pretty stable for STABLE and HALT-HOLD.
However, I noticed that HALT-HOLD has a different behaviour according to the altitude, therefore the sensor usedto read altitude:
since the Baro/sonar data are merge in the code, don't you thing we should addapte the PID settings according to which readings is taken into account?
We can Assume that sonar values are instantaneously up to date, and the delay Sonar/Baro can be computed when Sonar and baro are working within 30cm and 7m altitude range. here in the example there is a ~150 loging steps delay.
So I see 2 options:
Here a video of the T3 Two rounds mission competition simulation done with an helicopter (type 30 in H1 mode) with the firmware ArduCopter v2.2 b2xp3. The firmware is connected in HIL mode with an APM v1 (APM 2560) board through the Mission Planner v1.1.20. The flight plan follows the path of the T3-2 competition mission rules.
This simulated mission is done with AeroSIM-RC v3.81 (retail version) and its HELI-30 virtual model.
Regards, Jean-Louis
I must congratulate Jean-Louis Nadim. Your firmware version 2.2b2xp2 works very well. I was making a test flight just about 30m ago. Perfect day, clear blue sky, +/- 13ºC, almost 0km/h wind, sometimes 5km/h. Tested modes : Stabilize, Loiter, RTL and AUTO
Stabilize : Very stable, but it was already
Loiter : It continues to drift, I believe there's not much more things to do here without going into inertial control.
RTL : Here are the great improvements no doubt. Great RTL (I had 4m/s NAV but it can go to 6 without problem), It arrived home, and started landing at a great and confortable rate, touched the ground and jumped once but after that remained on the ground. There's just one note : It did not shut down the motors nor disarmed them, they remained working at about 1/10 speed.
AUTO : Worked very well, I'm sorry I don't have logs becaus I erased them accidentally, but if everything goes well, I will make another flight this afternoon, and get back with reports, I'm trying to find a cameraman to make a film of it :)
I have just one comment to AUTO, I don't know if it was from the waypoints beeing too close, but it seemed to me landing was started at the waypoint before the last, so I will try to clear that out this afternoon.
I will try to get back here after lunch with full documental proofs :)
Be handy if we could expose the 'simple' flag via MAVlink and display it on the HUD at somepoint. Given that requires code in ArduCopter and the Mission Planner - who do I talk to?