Version 2.4 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area. Although not as big a change as the 2.3 release, it still includes a respectable number of enhancements and bug fixes.
The default PIDs are optimized for a 3DR/Jdrones quad with 850 motors and 10" props. If you're using more powerful motors/props, start by turning down Rate Roll P in 25% steps.
Thanks go to the numerous contributors including users and their detailed bug reports, developers and testers. Hopefully all together this will add up to a nice smooth release!
As per usual, please post your comments, issues in this discussion. For enhancement requests for future versions, feel free to add them to the issues list. Note: you can "star" an issue to receive emails when someone comments on the item. On the dev side it helps us because we can get an idea as to which feature requests are the most popular by sorting by the number of people how have starred each issue.
Robert - so what about the initial transition from Stabilise to Loiter? Should we have a Stab_I value to build up a wind compensation (drawn from the attitude on invoke?)? What about the current entry criteria? I understand those to be that you can't have user input (i.e. manually holding it in place, giving it an attitude). Unless I am doing something wrong, at the moment we do have a "hiccup" with pitch changes and the copter being blown back in a wind. This is the problem that I am trying to describe in Issue 361. Regards, Bill
Randy, Bill, Robert & Dave - thanks for joining in on the loiter policy challenge!
The friction/no friction issue is present in both strategies, since they ultimately output attitude as the response to position error. Seems like my main objection to speed strategy is the calculation detour and presumed lag which is introduced by the speed management. But I can see the advantage regarding transition (to traverse) I-term transfer. Possibly also in optical flow sensor fusion (?).
However, there is one thing I do have a firm opinion about: When commanding loiter entry while copter is in a fairly steady state (stationary hover) the lat/lon attitude at entry should be used as a attitude reference /I-term bias/ to start out from. I support Bills issue on this (please see issue tracker).
I guess the whole loiter (lateral control) task would benefit massively by the introduction of a well performing inertial reference.
optical flow should help with the position control..just need to tune it a bit more and integrate it better in the loiter so that both GPS and optical flow can be used at the same time.
the inertial reference argument comes up a lot but nobody's really got it working. There's simply too much noise in the accelerometer values we use to make it work on a copter. If you can find someone to prove me wrong we'd all be very happy!!
I'm not sure about the lag argument..the control loops run very very quickly...whether there's one or two or three in series, it's milliseconds in any case.
Ok about optical flow
By the way, have you studied the HeliCommand Profi? Captron (the manufacturer) was a pioneer in using optical flow for position holding and ground speed management.They also use optics for low level height measurement (up to max 3m, I think). I have one of these units on my MaxiJoker 2 photo ship. One can choose to select optical / optical+GPS / GPS as position reference using one of the control channels. I does "seamless" transition if optic conditions are insuffiecient, but if one know from the beginning that it will have difficulties (over water, snow, trees / roofs), better to disable optic and just use GPS (which works good!)
Another feature to take note about, regarding HeliCommand Profi, is that they have got a pressure port that connects to the pickup via tubing, so you can mount it at the point (normally close to rotor shaft) that offers the least disturbed air. That solution should be considered for APM too, especially for use in trad heli.
About inertial reference.
Yeah I have heard about the noise problem. Still, this method has been applied in rockets and aircrafts for a long time. And a rocket with engines engaged surely comes with extreme vibrations. Suspension might be one part solution and robust filtering (Kalman?) another part.
The lagging I referred to would not be due to the control loop; rather by the GPS update interval. Speed calculation needs at least two readings, while position just requires one. By the wandering nature and relatively low resolutionof GPS position readings it seems to me like the precision in speed calculated from this would be relatively low, compared with the precision of the reported position deviation. Though, I lack the mathematical means to prove that.
Great info Tomas thanks, optical flow is my next big project (i.e. listen to what everyone is saying and then test it to death)
Keep talking :)
I've just loaded the latest code and hovered around the garden a bit.
Only used Stabilize mode, is VERY stable.
Thanks dev team !
roll and pitch angle are converter from RC to a max of 45 degrees:
But later are constrained to 25 degrees:
// limit the error we're feeding to the PID
target_angle = constrain(target_angle, -2500, 2500);
This means that joystick usefull travel is only about 40%.
Wouldnt it be better:
#if FRAME_CONFIG == HELI_FRAME
Can we get banking angle adjustable from Mission Planner?
Can we get a speed limitation in stabilized mode?
I would be nice to be able to travel at a certain adjustable speed also in stabilized mode.
Can some of the Gurus provide a way to calculate the forward and lateral speed of the copter?
don't know if you'll see this reply as this thread moves quickly. ..anyway, what you've missed is that at the top of the get_stabilize_roll function it changes teh meaning of target_angle to actually mean angle error (slightly bad form I know!). So the 25 degree constraint is a constraint on the difference between what your radio says and what the attitude of the copter is.
// angle error
target_angle = wrap_180( target_angle - dcm.roll_sensor );
I`ve noticed it long after posting.
For a newby like me is a very interesting way of programming. Apples can become Bananas at any time ;-)
I've been tuning git-latest (7956f84e8...) on a jdrones hexa with the 880kv motors. Whilst its improving with tuning - the most disappointing thing is that it feels far worse just hovering than a month back. I've changed the APM2 mount to the recommended mount (o-rings) as though it flew ok before, it was suffering from the 'leans' over a floght. I've changed the leg mounts to get the CoG more central. Both of those should improve matters I thought.
I ended up with Stab P of 4.5, Rate P of 0.10, no I and Stab D of 0.01. Whilst it hovers okay for a while (even hands free), it will suddenly lurch off in a direction and occasionally oscillates. Its leaving me with little confidence and no inclination to go and test alt-hold and loiter :(
octa x468hd APM2 default pid's . alt_hold is ok 20-30cm, loiter no sign of such work. increase the P? gps is 3d-solid blue.