Ardupilot 2.1 is out and can be downloaded by the mission planner (or with Git). You must have the latest version of MP to be compatible. If you're compiling with Arduino, you must use the "mrelax" version of Arduino that is in our downloads section. This is because Arduino was never tested with code larger than 128K. And since our code is probably the most complex Arduino project ever, we found the issue. This altered version of Arduino allows you to specify a special compiler flag that makes it work again. Otherwise it's functionally identical to version 22. When we transition to 1.0 of Arduino, you won't need to use a modified version, since they have patched it for us.
This version has a few new features, but is mostly a bug fixes and compatibility with APM2. The nav routines have been updated and well tested. I'm getting very reliable results now.
One new feature that I snuck in was SuperSimple mode, which re-calibrates simple mode when you are flying with GPS > 20m from home. It allows you to fly in any direction in Simple outside of this radius. Check the wiki for more info.
Added Auto_land mode to help with Failsafe implementations.
Here's a video I took flying WPs using CH 7 to toggle record them. I flew back and forth over the park to se how straight a line I could maintain and how repeatable it was, then I recorded a few waypoints to the left and right, then I recorded a landing wp by toggling CH7 when the copter was on the ground. The landing could be improved, it was trying to maintain a location and didn't level out in the last meter to the ground as it should. I was missing the screw holding my Arm in place so it folded in just a bit, no real damage done. BTW, this video is W/O a sonar.
The next video is of the Loiter control. I improved loiter a bit with a bug fix and the stability patch from the stabilization. Wind was mild. Could be tuned just a little higher.
Here's a video from Dec 17 showing WP recording. The radio was on the ground the entire video. The 3DR frame did not have a sonar on it. The landing was recorded as well.
Upcoming:
Tridge wrote a Geo - fence routine to restrict flight within a certain area for Arduplane. We'll port that over to AC. You'll be able to fly acro inside a safe area and have it go into AP if you loose control!
We need one more pass to finalize the Optical flow integration.
Finalization of the Z Accel code.
Have fun and fly safe,
Jason
Replies
This is the 3 flight i did.
The two flights on 9:29 and the one on 10:25 are the on ended with a crash.
2011-12-20 10-25-59.tlog
2011-12-20 10-16-27.tlog
2011-12-20 09-26-36.tlog
2 CRASHES !!! with the 2.1 version
while hovering in ALT-HOLD suddenly all motor 6 stopped.
I managed to move to Stabilized the motor came to life but the Y6 wasn't leveled so it was to late, but i only broke a prop.
in the second try all was ok.
the third time, same thing the motor stopped while hovering on ALT-HOLD, again move to STABILEZED but it was to late.
ALL SMASHED :(
I cant mange to enter the CLI log (1280)
I was thinking of implementing something around this code:
#define ERR_GAIN = .01
float scale = sin((float)nav_lon * RADX100)); // guess our X location based tilt of copter
xLon_estimate += thrust * scale; // thrust is a guess, needs to be calibrated based
xLon_estimate -= ERR_GAIN * (float)(xLon_estimate - current_loc.lng); // error correction
plus same for nav_lat.
This is a total guess, however it takes into account the pitch and roll to guess our rate between GPS calls. It would also smooth out the GPS.
Does any body know what is "pathplanning" (WP) command in the APM planner ?
I made the recomendation to try GPS velocity, and I don't know if those suggestions influenced your test changes or not, but in any case some comments on my system that might be appropriate...
I had the following loop:
Desireed position vs actual position gave me a desired velocity N/S and E/W to correct the postion.
Then this was transformed with the true heading (taking in account the compass deviation)
to desired left and desired forward velocity.
This velocity was used to generate desired pitch/roll from desired velocity with an P, I and D term.
This was the ONLY I term in the whole hover in place loop.
My GPS direectly spit out Ve/w and Vn/s as well as Vup/down I did not have to convert course and speed to these values.
Paul
I just read through the latest posts from the weekend, and I think we're at a "where do we go from here?" point. It sounds to me like all the *bugs* with the existing code are worked out, and we are about as good as we're going to get with the existing scheme. A classic PID control system will just not give us the performance we want. It is always destined to overshoot if tuned for maximum responsiveness, or else you can "numb" it a bit for slower response with no overshoot. Neither of these situations is what people want. And this situation is made worse by the fact that we don't even use derivative term on most of the corrections.
It sounds like Emile has found an interested thing to look at with the heading update. I've seen similar behaviour from high precision GPS mapping systems. When you're standing stationary, the heading display is really flaky.
I also think that expecting any device to remain stationary (<1m) based solely on GPS signals is a pipedream. You can see how much the GPS signal moves around just by zooming in on a GPS map. Anybody can see this just by parking your copter on the ground, and watching the display in Mission Planner. The copter icon moves around when the copter very clearly is not. 3m accuracy is really the best that can be expected.
Is it true that the loiter control algorythm only looks at GPS signals? No dead reckoning based on the accelerometers?
Is there any consideration being made to gain-scheduling the PID terms as I suggested about 1 week ago? That's one "easy" way to sharpen up the response of the system without creating too much overshoot.
Long story short, a great thanks to the team for their tireless effort, and all who contribute here for their wanten progression of a fantastic concept. Well done all. (rant over, please continue :-)
Here is a maybe a simple solution for more stability:
Will it get better stability and a smooter regulation using governor esc's used in trad traditional helis.
APM will be able to command these esc's to exact RPM that maybe extracted from a table that is intended for propeller and engine size. Such a table is easy to make for different engines and propellers by measuring the speed and thrust at different RPM. This setup will give the esc's more of the work with steady thrust. These esc's are able to maintain a very precise RPM regardless of load.
I'm delighted that ArduCopter had reached the level of sophistication that people are now benchmarking it against the leading closed-source commercial multicopter controllers. And with the progress that Jason and the rest of the dev team has made in the 18 months that ArduCopter had been in development, I'm sure that it will equal their performance, especially with the new APM 2 board.
But I wanted to point out this it's a little bit of an apples-to-oranges comparison when you take into consideration price, real UAV mission planning, and hackability. Quite surprisingly, with the exception of Mikrokopter, the closed-source multicopter controllers aren't capable of real UAV missions, since they don't allow waypoint mission planning and scripting like ArduCopter. That's one of the huge advantages ArduCopter has: it's built on a real UAV platform (APM/ArduPlane) that has years of mission planning development and experience with many thousands of users.
Closed Source:
Hoverfly Pro with GPS: $900 (just GPS hold and RTL: no waypoint missions)
DJI Wookong with GPS: $1,100 (just GPS hold and RTL: no waypoint missions)
Mikrokopter with GPS: $900 for all three boards required (rises to $2,400 if you want waypoints with 500m distance)
Open Source:
ArduCopter with GPS: $200 (GPS hold, RTL and unlimited waypoints at unlimited distance)
Hi all! I decided to launch my metaphorical "N" bomb! :-)
This is the video (at the end) about loiter test with my heavy octo and V2.1 software release.
Maybe someone watching the video will think "but it is still building!", unfortunately if you think this has no terms of comparison or has not looked the second and third parts.
I state that my hover in STABILIZE is at 50% of the throttle stick and that in the stabilize flight the drone behaves quite well.
But back to the question loiter: in the absence of wind does not behave badly, unfortunately it seems very simplistic to decide whether to use ArduCopter because it does not move a leaf or Mikrokopter/DJI because there is a tornado (LOL).
ArduCopter is not use the accelerometer for mantain the position in loiter mode, disabled by default because does not work properly, so the error doing by a errors caused by abnormal or intermittent readings of the GPS are not managed as well as the annoying circle effect.
Also there are strange variations of the engines on my system when i correct the position of loiter with ALE, dunno why, i just put a little "left ALE" correction (see video for this at 1:39)... in loiter with 2.0.49<->55 the problem is absent.
I know there's two loiter mode in this release but this one is the default, if the other is better do not understand why not enter it as primary.
The variations in speed of the engines are too dry issue on my system (read if you want to some of my previous posts about this), not smoother, and causing continuous little wobbling.
Concluding, IMHO about the loiter in 2.1: is not an upgrade but a downgrade if my drone goes too loud from the recorded position.
Want some parameters can be modified in order to adapt the pwm rate corrections (logaritmics, not linear, and too smoother) for fine tuning the motors rpm according to the size of the drone, props and motors, i'm not talking about PID, and the accelerometers are managed to anticipate the drift errors generated by the GPS/wind... enough of these circles, we want some square! :P
Besides, we do not have all the original ArduCopter DIY Quad, and the dear Jason can not do miracles testing its release only on his standard DYI drone.
The alternative would be to make buyers aware that the system works properly if installed on DYI configurations.
I hope these problems will be solved seriously, significantly considering the advice of users with a "non standard configuration" because i believe that exceed those that use a lot of DYI kits, or i will have to selling out or giving away my APM and sonar with displeasure.
I think it's useless to fly the drone automatically if first you do not have acceptable stability in the management of the precise position with gps (i mean no more than 3 meters in the absence of wind without circle effect)... the others additional features are negligible if the primary does not work well.
And if can not possible thanks anyway to all the developer team, it was nice to test the world's most popular free Arduino flight system, sin not wanting to use it to play does not make my case (as it does now).
Follow with interest your comments / criticisms, thanks!
Best to all!
Marco
https://www.youtube.com/watch?v=pyBl9Xq0ls8
-
1
-
2
-
3
-
4
-
5
of 7 Next