Replies to This Discussion

DeveloperPermalink Reply by Marco Robustini on January 11, 2012 at 7:09am

I'm at the arifield now for testing R9.
The first problem is in autoland, touch the ground but with infinite little jump, and in the first test it's impossible to disarm the motors, i follow the jumping quad, taking with my hands (with motors armed, low speed but with rotating props) and disconnect the main power... this is not good! :P
First i tried to change to another mode, without success, the only way to disarm the motors is remove the power lipo..... :-(
The sonar it doesn't work fine, removed from the configuration for session of this test.
Dunno if there's this function but if i put a little throttle when the motors are armed, and the going to zero throttle after 30 seconds there's automatic disarm, like yaw to left... i see because i've led, and going off after 30 seconds... it's normal? :-)

• ▶ Reply

DeveloperPermalink Reply by Jean-Louis Naudin on January 11, 2012 at 8:45am

Hello Marco, I agree with you... I have done some tests flights with my quad in the field with the R9, the autoland need really to be improved in most of case the land doesn't start and the quad do an infinite LOITER at the RTL altitude above the home. Then, in case of land, the quad bounce and bounce again on the ground. The STABILIZE, ALT_HOLD, LOITER, RTL are still OK and good as usual for me....

Today, we need to focus on the RTL switching to LAND timer and also to the final touch down for avoiding the infinite bouncing...

Regards, Jean-Louis

• ▶ Reply

Permalink Reply by afernan on January 11, 2012 at 9:11am

I think that the simplest solution is the one of r7: to continue descending up to throttle 0, even after touching ground (throtle straight soft descending line)

With that, we avoid to detect the floor, whatever it is, and progresively the motors with go to zero.

Angel

• ▶ Reply

DeveloperPermalink Reply by Marco Robustini on January 11, 2012 at 9:23am

Nice JL, this means that there really is a problem, but the real thing is the inability to disarm the engine when it bounces, at least this has happened to me before.
I ended the test session because one prop support it slightly wrong, and the quad was vibrating a lot.
Anyway about the automatic disarming of the motors if the throttle stick is to the lower position?
This function is enable also in Stabilize, Acro, and i think in AUTO, I can not imagine what can happen if you put the stick in AUTO mode to zero (AC managing the throttle in this way) for more than 30 seconds, I hope that Jason checks this well, you may activate this feature only if the quad is stationary on the ground, controlling the value of gyro and accelerometers.
If you try to arm the motors, give a wisp of gas, return with the throttle stick to zero, move in your hands the quad and wait 30 seconds... motors are disarmed..... :-(( ?!?!?!?

@Angel: yes, R7 autoland correctly with AeroSim and I also believe in the reality, is the only one that kissing the ground and land (in my test with AeroSim) and nothing to do with the R9.

• ▶ Reply

Permalink Reply by u4eake on January 11, 2012 at 3:10pm

Marco, the following code in arducopter.pde explains the auto-disarming after 30s

// this function disarms the copter if it has been sitting on the ground for any moment of time greater than 30s
// but only of the control mode is manual
if((control_mode <= ACRO) && (g.rc_3.control_in == 0)){
auto_disarming_counter++;
if(auto_disarming_counter == AUTO_ARMING_DELAY){
init_disarm_motors();
}else if (auto_disarming_counter > AUTO_ARMING_DELAY){
auto_disarming_counter = AUTO_ARMING_DELAY + 1;
}
}else{
auto_disarming_counter = 0;
}

• ▶ Reply

DeveloperPermalink Reply by Marco Robustini on January 11, 2012 at 3:52pm

Thanks u4eake, removed from my code, don't like it...

• ▶ Reply

Permalink Reply by steve F11music.com on January 11, 2012 at 11:10am

I know that a simulator is used on every new release to catch bugs but shouldn't each version be flown through a preset WP including takeoff and landing and using the standard 3DR kit with options like sonar. The path could test various functions like is done already in the simulator. This was we can be sure that all things work like sonar on alt hold, auto landing, function of different flight modes and complicated WP mission and if the same thing is not working for our copters then we know it's something particular to our craft and not the general code.

I think Jean-Louis and others are taking the place of this but it should really a set complicated mission should fly with success of all functions before being considered releasable.

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on January 11, 2012 at 11:30am

F11: that's exactly what the Autotest system does. Every code release is tested against a full mission, with automated test results and error diagnostics.  The vast majority of what people think are software bugs are actually setup errors, hardware problems, non-standard airframes that haven't been tuned and user error. Every now and then a real bug is identified, but almost all of those are caught before release in autotesting.

• ▶ Reply

Permalink Reply by Tomas Soedergren on January 12, 2012 at 2:37am

Excuse me Chris, but I don´t think that is EXACTLY what the Autotest system does.

As I understand it, @F11´s point is that release versions should be FLOWN, not only simulated. Taking the test into the real world, outside the world of computer models. 

I regularly find myself inside multi million dollar class simulators. They are really really good. Close to real. But not real. And that distinction is significant. I second @F11´s suggestion, please consider it.

• ▶ Reply

Permalink Reply by Geir Engebakken on January 12, 2012 at 2:48am

It would of course be more bugs found using real life testing. For example the Auto WP overfly bug that was found by Jason from my logs after crashing several times  was not caught in the simulator test. Why? Because real life made the quad overshoot the WP so much that the bug was triggered. In the simulator the quad followed the path to closely for this to happen, I guess due to a simplified physics simulator.

But then I guess to implement an automated real life test suite, is perhaps to ask too much. But RELEASED versions of the AC source should be tested in real life, I think that is a must!  

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on January 12, 2012 at 5:32am

But, released versions (APMP Hexes) are already test flown.  They don't push a hex out until it is test flown.  Trad.Heli hex is currently way far behind the current developments because Randy hasn't had the time to test the latest.  I've flown r8, but I presume they want to wait until Randy has.

And that's the catch.  The more requirements you put on the developers, the slower things will happen.  The slower it is for things to be released, and that also takes away from their coding time.

That's why the .zips are put out there.  These are pieces of semi-stable code which the beta testers can use.  If enough of these guys test it and it's good, then it will be released.  But at this moment in time, I think we're in a place where the basic code is pretty good, and the developers and testers are playing around at high-speed trying to get perfection, and just haven't had time to really think about pushing out a hex.  

So, you just have to decide what you want. If you want the most stable, but potentially lower performing code, use the hexes.  If you want to help test the latest code, download the .zips.  But make sure you know what you're doing, because you may encounter bugs.  Marco lost his big octo because of this.  And also try to make sure you know what you're doing because reporting false bugs gets everybody chasing ghosts.  And if you're *really* good, help develop the code right out of GIT.

Just remember, all the developers are volunteers, and I presume have day jobs, and only have so much spare time.  The more time they spend testing the latest codes, the less time they can spend trying to make it better. 

• ▶ Reply

Permalink Reply by Gustav Kuhn on January 12, 2012 at 3:03am

I have a TREX 600 Nitro, set up in "Sport" mode.

It flies really nice, in real life, very forgiving, I set it up myself.

Phoenix V3 has a TREX 600 Nitro, in sport mode, flies like a POS.

I don't have much in the line of tertiary qualifications, but I design, and build stuff for the saltmine, that works.

We get these highly qualified youngsters, knows all about CAD, Matlab, that kind of stuff.

And that is where it stays. On the computer.

When, infrequently, they put soldering iron to pcb, it blows up, everytime.

(They get paid, and promoted, better than me)

I don't like sims.

• ▶ Reply

• ‹ Previous
• 1
• …
• 53
• 54
• 55
• 56
• 57
• …
• 68
• Next ›
• Page