Replies to This Discussion

Permalink Reply by Cliff-E on February 27, 2012 at 6:03pm

Can't wait to try 2.4.2, still working with 2.4.1. I'll up your loiter test:

Winds NW at 12mph constant (19kph), 15mph gusting. And slight drizzle this morning. This is not typical LA weather... Loiter mode starts 5sec into video.

Untitled from recharged95 on Vimeo.

• ▶ Reply

DeveloperPermalink Reply by Randy on February 27, 2012 at 9:30pm

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.

• ▶ Reply

Permalink Reply by John Campen on February 28, 2012 at 7:17am

Randy when you fix a bug does it also get fixed in the 2.4.1 on Mission Planner as well?

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on February 28, 2012 at 10:00am

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.

• ▶ Reply

Permalink Reply by Tomas Soedergren on February 27, 2012 at 2:34pm

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?

/ Tomas

• ▶ Reply

DeveloperPermalink Reply by Randy on February 27, 2012 at 9:58pm

Tomas,

     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.

• ▶ Reply

Permalink Reply by Tomas Soedergren on February 28, 2012 at 11:58am

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...

• ▶ Reply

ModeratorPermalink Reply by Graham Dyer on February 27, 2012 at 11:47pm

@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"?

• ▶ Reply

DeveloperPermalink Reply by Randy on February 28, 2012 at 1:11am

Graham,

     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.

• ▶ Reply

ModeratorPermalink Reply by Graham Dyer on February 28, 2012 at 2:01am

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?

• ▶ Reply

ModeratorPermalink Reply by Graham Dyer on February 28, 2012 at 9:43am

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.

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on February 28, 2012 at 9:51am

Graham, rest assured that Tridge is now attacking this problem.  

Hopefully we'll have something soon.

• ▶ Reply

• ‹ Previous
• 1
• …
• 48
• 49
• 50
• 51
• 52
• …
• 90
• Next ›
• Page