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
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 ?
LOITER and ALT_HOLD in 2.0.49: back to that!
As many of you, I also have bad Loiter and bad Alt_hold.
But I remembered very good performance with ´49. So I´ve installed again and flight tested: LOITER perfect (no circling) and ALT_HOLD much more stable (same copter obviously, default PID)
For me is very obvious that is much better in both Loiter and Alt_hold. I do belive that the new PI+I estrategy (add I term to output) is doing something bad w.r.t. circling in loiter and ALT_HOLD (I don´t know why)
So I decided to recover that loiter code form 2.0.49 and I´ve introduced in 2.1-alpha code (for the moment only in LOITER_0).
I´ll test it tomorrow, and I´ll report. If someone want to test it, attached is the modified "navigation.pde" file (replace the one in 2.1.0 alpha and load with arduino).
Please, use with care and at your own risk!. I´m not an expert programmer.
Angel
navigation.pde
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.
I think two layered PCB with so many connectors may be a serious reason of noise and abnormal behaviors. Not necessarily every PCB with high speed need Signal integrity tests. I have seen very low frequency signals at times generating havoc in circuits if not taken care properly
HIL under AEROSIM-RC with a quadropter
I´ve succesfully ran the HIL 2.1 code for a quad under AEROSIM-RC simulator. It´s really worth to check it out.
You can follow general instructions on the wiki (http://code.google.com/p/arducopter/wiki/TradHeliHIL). For the particularity of the AEROSIM I´ve done a small video with the MP configuration and my Tx (Futaba FG8 super) http://vimeo.com/33870023
It´s really usefull to play with all flight modes exacly thesame than in real flight. To play with loiter parameters and see the result in real time is very usefull and teaching. Something very usefull also is to add wind with gusts and see the reactions (I´ve spent whole yesterday playing with that).
You must install first the HIL code for "quad" in MP . Configure MP (see my video). Then copy the file "plugin_AeroSIMRC.dll" included in the MP directory to the Pluin directory of AEROSIM. Once inside AEROSIM, you must run this plugin to connect with MP.
I´ve selected the model "MK quad" (800gr, batt = 2.2Ah) that is very similar to the one I have.
Don´t doubt: check this out: It´s fantastic!. I´ll open a blog dedicated to HIL experiences and tips.
Angel
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 :-)
Many Kudos to all in this project- Jason, Chris, JLN and the rest of the devel team! The dedication and motivation is awe inspiring. After a couple years of dabbling, I got serious this year. I have been ordering parts for my project over the past few months- all the while learning from you all through the study of this forum. The ongoing process of improvements is impressive and admirable. As an end user (noob!) who would love to contribute more, I see a tall hill of a learning curve ahead of me- but then I have to look back down at how far your sharing has already helped me climb up this fairly steep grade. This is a very cool and very sophisticated flying robot that just keeps getting smarter. Sincere thanks all. Its been a fun process thus far- I can't wait to fly!
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.
-
3
-
4
-
5
-
6
-
7
of 11 Next