Arducopter 2.2 beta
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 to This Discussion
-
Permalink Reply by Jani on -
I finally got it working. I was using old winrar to extract AeroSimRCAPMHil.zip without any errors or warnings, but now it seems that problem was there. Today i deleted those plugin files and extracted again using 7-zip free software and everything worked :)
Regards Jani
-
Permalink Reply by John Campen on -
I still cant get sim/flightgear working properly either. I only have acro working and all other settings just get the yaw oscillation regardless of the settings and PID adjustments. Is it possible someone can see if the HIL firmware is ok?
In the mean time Ill try loading and earlier version
-
Permalink Reply by Tobias Krieger on
-
PLEASE note that the tri version 2.2b4 does not work! Loaded through MissionPlanner and Arduino; both ways do not give any TRI_YAW servo outputs (CH7).
Downgraded to 2.1 and everything works well.
Had a quick look on the code, but cut not find a reason (newbie). Maybe something here (that's the new part in 2.2b4 vs 2.1)
#if CONFIG_APM_HARDWARE == APM_HARDWARE_APM2
/* TODO find out correct channel for APM2 TRI_YAW */
# define CH_TRI_YAW (-1)
#elif CONFIG_APM_HARDWARE == APM_HARDWARE_APM1
# define CH_TRI_YAW CH_7 #endif
I have the blue APM with the 2560 (I guess it is V1?)
-
Permalink Reply by Don Brooks on -
Tobias,
I'll be working on the yaw of my Tri tonight. I have noticed that it doesn't react to stick inputs, but does react if I pick up the copter and spin or twist it from side to side. Have a look at this thread. Read through the comments, as tehre seems an update for 2.2b4 (ignore the ones where some guy hijacks the thread for his firmware upload problems).
I messaged Jason about it, but never saw any result or change in the code. Perhaps it's not needed, as I said, I'm just getting started on getting my yaw to work tonight.
-
Permalink Reply by Tobias Krieger on
-
Don,
Thanks for pointing me there but....
;-)))
It was me (Tobias) who wrote the possible update info in this thread but still it does not work (and it was me who answered a guy (Javier) how to upload the firmware through Arduino ;-)) (Yhea and I switched to spanish...)
Exactly, no stick input, but in my case the servo output seems really "dead".
-
Permalink Reply by Don Brooks on
-
hahaha, ok now I kinda feel stupid...
But I'll play around with mine when I get home, and I'll either PM you or start another thread to go over tri yaw troubles. Not starting at neutral mid-stick outputs is the first thing I want to look at, because on mine when I power up my APM, it kicks hard over when the servo gets the 900 PWM output.
Unless of course, Jason can blink, wiggle his nose, and magically make it all work... but I don't know if it's a code problem or not yet. I do know that my yaw servo and mechanism is centered, and works well when directly connected to the Rx.
-
Permalink Reply by Don Brooks on
-
ok, so ya on 2.2b2 I was getting some movement on the tri yaw servo. It acted somewhat erratically, almost looking like the hinge was bound up, yet it moves freely when connected to the Rx direct. on 2.2b4, the yaw servo doesn't move at ALL, not when I give throttle, wag the frame to and fro... nothing.
-
Permalink Reply by Don Brooks on
-
Tobias,
I could be horribly wrong, but I think I figured out why the yaw servo seems dead. On this change, the outputs are all disabled on initialization. On this change, the motors are enabled later on. However there doesn't seem to be any measure taken to enable the channel 7 output. I do see something similar taken into account when FRAME_TYPE is HELI_FRAME on this change.
I think that's the why. I just don't know how to go about fixing it! There's some examples here, but it's late and I need to put away my toys and go to bed...
-
Permalink Reply by Tobias Krieger on
-
Don,
Thank you very much for your support, I got late nite during code reading almost the same impression. ... :-( ... I need some time to find a fix, if someone else is not faster.....
-
Permalink Reply by Tobias Krieger on
-
P.S One fast and furious approach might be to add in the tri_motors.pde something like enable(ch_tri_yaw).
-
Permalink Reply by Don Brooks on
-
Good call, that's what Pat did here, so it should be fixed on the next release. Pulling from Git should give you a working version also.
Thanks Pat!
-
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
-
techpod users
39 members
-
Moderators
24 members
-
ArduCopter User Group
1286 members
-
Turkish Ardu Group
5 members
-
ArduRover User Group
184 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
