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.
We're most likely going to start the beta testing of 2.4.2 very early next week (like Monday Mar 5th-ish).
We're making good progress finding and squashing bugs here and there so we think another week on our current path is the most efficient way to go.
Randy when you fix a bug does it also get fixed in the 2.4.1 on Mission Planner as well?
No. Generally speaking, the code that exists in MP under a given rev number is static. 2.4.1 was released into the Download, and MP, and it is now frozen. The changes in GIT will become 2.4.2 in the future.
It may sound like you are going to have to live with some bugs in 2.4.1 for 2 weeks, which may be frustrating. But rest assured that nothing we have found is new to 2.4.1. What we're working on is fixes to OLD bugs, or new performance improvements.
This is the only way to work. We can't be pushing changes into MP every other day. Everything has to be test flown first, and if we concentrate on test flying every change (there are sometimes 10 in one day) so that we can push it to MP then it will slow down the process too much.
2.4.1 is "good enough" for now. We have to be allowed to work behind the scenes without having to support users for every little change that is made.
Observation regarding x & y axis (or long & lat) speed and attitude constraints in the code, e.g. navigation.pde
Constraints like the one in this example code results in effective constraint for diagonal (simultaneous movement in x and y) movements that is 41% (square root of 2) higher than fore movements purely along one axis. Seems sub optimal (wrong) to me. If it is not taken care about elsewere in the code?
// East / West
x_target_speed = g.pi_loiter_lon.get_p(x_error); // not contstrained yet
//x_target_speed = constrain(x_target_speed, -250, 250); // limit to 2.5m/s travel speed
x_rate_error = x_target_speed - x_actual_speed; // calc the speed error
nav_lon = g.pid_loiter_rate_lon.get_pid(x_rate_error, dTnav);
nav_lon = constrain(nav_lon, -3000, 3000); // 30°
// North / South
y_target_speed = g.pi_loiter_lat.get_p(y_error);
//y_target_speed = constrain(y_target_speed, -250, 250);
y_rate_error = y_target_speed - y_actual_speed;
nav_lat = g.pid_loiter_rate_lat.get_pid(y_rate_error, dTnav);
nav_lat = constrain(nav_lat, -3000, 3000); // 30°
Comments on that?
Nice observation and good suggestion! So you're saying that there should not be a separate target speed calculation for x and y but instead a single target speed calculation which is later divided into x and y components. This would nicely reduce our number of parameters by one as well.
Thanks Randy, yes - you got it!
At least I am saying that throughout the entire AC code base, the multitude of vector representations involved in attitude and navigation management e.g. X/Y (frame axis), Lon/Lat, and various polar representations (frame relative, true north relative, magnetic north relative, etc...) should be carefully scrutinized and for all instances it should be considered which representation serves us best and what implications they may have. I am sure that at great extent this consideration has already been done, but maybe some ArduPilotmega solutions (fixed wing) has made their way over to ArduCopter without anybody reflecting so much about the different nature of freedom that a multicopter posesses.
I do believe that in many cases we would find that the polar would be the best choice. Then again, I am not a programmer...
@Randy, this thread moves so quick things get left behind, any comments on a minor issue I raised: here
Basically to tighten up on control so it doesn't feel like you're flying with "loose linkages"?
I've raised it as an issue here. To be honest, it'd be nice to see a bit more hard evidence like some logs files.
For example a good test would be:
1. fly your quad...set the level...take a quick video of it not moving around
2. land your heli..restart the APM
3. fly your quad, show that it's now moving around
In this way you know that the environmental conditions are all the same and it's really a code issue. If on the other hand, the level of wind was different or your battery was out of place and affected the CG, there might not be much we can do about it...I think.
By the way, Tridge and Pat from the dev team did find some issues with DCM filtering so it might be related.
Thanks, it's a difficult thing to quantify and explain properly, not sure if the logs would show it accurately either. Also the "feel" (to me) is basically always there, it's not that after re-levelling it's gone. It may easily be a hardware limitation with APM1 as I have not yet put APM2 back on my quad so can't comment (yet).
I was wondering if there was a code tweak to "tighten" the control feel up but maybe it's at it's "tightest" already?
I put my APM2 back into the quad after many good flights with APM1 over the weekend, bolted the APM2 to a same size piece of vero-board for weight and a firm surface and then with the same velcro mounting method and guess what... the leaning problem is still there (%$#@&^$#!!!!).
Sometimes not as severe as before but the slow accumulating lean is present and I even had the sudden-death lean too in the same flight which has never happened before.
I have some new logs and combined with the logs/graphs already posted will raise an issue in the tracker.