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.
here is the error on a new installation of 022 arduino relax:
ArduCopter242xp2.cpp: In member function 'void ::GCS_MAVLINK queued_param_send ()':
GCS_Mavlink: 1678: error: no matching function for call to 'AP_Param :: copy_name (char , unsigned int, int)'
C: \ Users \ user \ Documents \ arduino-0022-relaxpatch \ libraries \ FastSerial /.. / AP_Common / AP_Param.h: 101: note:Candidates are: void AP_Param :: copy_name (char *, size_t)
ArduCopter242xp2.cpp: In function 'voidLog_Write_Performance ()':
Log: 650: error: 'class AP_DCM' has no member named'renorm_range_count'
ArduCopter242xp2.cpp: In function 'void calc_loiter (int, int)':
navigation: 150: error: 'class AC_PID' has no member named'set_integrator'
navigation: 151: error: 'class AC_PID' has no member named'set_integrator'
ArduCopter242xp2.cpp: In function 'void calc_nav_rate (int)':
navigation: 220: error: 'class AC_PID' has no member named'set_integrator'
navigation: 221: error: 'class AC_PID' has no member named'set_integrator'
the compilation of version 2.4.1 is ok
the compilation of your file is ok ArduCopter_224xp2.zip is ok
Randy, I think the current strategy explains the behaviour of Loiter in stronger and/or variable winds. At the moment, when Loiter is invoked, the position error is nil, so there is no speed or attitude fed in - the copter gets blown backwards and eventually reacts. If the relevant parameters are high enough (Nav P in 2.4.1?), the copter gets sufficient speed to regain the Hold Waypoint (and may or may not overshoot), but it does not seem to maintain an attitude to hold it, so there is a backwards and forwards cycle, complicated by phase lags, I terms, D terms and goodness knows what! I think that we need an algorithm whereby an initial attitude is taken as the start point (as described in Issue 361), and that attitude is maintained more or less after that. If position errors increase then increased attitude is invoked to correct, with some damping mechanism so that when the copter regains the Hold Waypoint, it does so with effectively zero ground speed and no acceleration vector, but just sufficient attitude to hold again.
I have not been able to compile 2.4.2 yet, but how have the strategy or mechanisms been modified? I understand that Loiter tuning is now separated.
No i can't get 242xp2 to compile and different errors. I'm sure its something I'm missing, but no idea what. Back in a hour to investigate.
Randy, isn't that how it was even 1 month ago? I think these changes are recent.
Tomas, I believe the idea right now is that Jason wants to run the Loiter through the speed loop so that the speed loop I-term (which then commands attitude angle) builds while in loiter, to achieve whatever number is required to maintain position. Then when you go into auto mode to fly a mission, the same speed loop I-term is used. The idea is that this creates an automatic wind compensation. Since there is a speed loop I-term for lat and long, it automatically winds up to a number that fights the wind. More importantly, when you switch between Loiter and forward flight, the I-term transfers from one to the other, which means that there is no period of no wind compensation while the new I-term winds up. It should result in a smooth transfer from one mode to the other, with no "hickup" when the copter is initially blown back by the wind.
Great information, thanks Robert.
It's good to know the thinking behind it all, it accelerates the learning process, for me at least :) Its also good to know that the issues raised recently, in the past few pages, regarding loiter are in the fore-front of what Jason and the team are trying to achieve.
Now will someone please zip up xp2 and send it to me if your not happy with posting it here.
I've got a massive field just sitting here, 8 batts full and fully understand the risks, think of all the lovely data :D
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 :(
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
Marco - one of the problems I have with the Mediatek is that it can take a long time (10 minutes) to get a 3D fix, even with it sitting on top of the stack. How quick is that ublox? Regards, Bill
Have you tried getting lock without the RX powered up? I found that my RX caused the same issue you're seeing. Ultimately, turning the RX through 90 degrees and moving it off to one side solved the problem.
My gps also use to take forever, it was sat right above my xbee and rx. I have moved all three of them away from each other as much as possible, the longest its takes to lock (even on cold start in a new location is under a minute with clear skies, under 2 when its cloudy.) Then warm locks are taking about 20 secs max.
I presume it was the separation of the components that improved matters as little else has changed physically (and i doubt my silicon gromets were the issue :))
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.
I have got it to compile, after a lot of fiddling.
I quite simply solved my problem by using arduino v.22 relaxpatch, instead of v1.0 relaxpatch.
Hope that help - now to upload it- yee haa! :)