This is a work in progress. I've tried to address some fine tuning and performance issues.
Denny R. had made a comment about the inertia of bigger props causing issues. I've added a low pass filter to smooth the positive acceleration of the props to see if we can get at this issue. It may require tuning up Rate_P for a few folks, but I saw little issue in multiple flights.
Crosstrack had a small math error that decreased the resolution of it. I've fixed that and upped the default gains to get better tracking.
Made WP hit radius 1 by default. even 3m is too much for quads. (If you pass a WP you will move on to the next)
The Loiter method is tuned a little better by default, and now uses GPS offsets when flying less than 1.5m/s. Code experimentation will continue on this front. Thanks to Emile and afernan for their help!
A fix in the Z Accel startup was added to get an averaged result.
Added the ability to enter Loiter with Optflow enabled. - still a work in progress, not for everyday use just yet.
This alpha is on GIT now and is for user's who want to test code. As always, you need to use the "relaxpatch" version of Arduino you can find in the downloads section.
Update: We've found and patched some small type bugs in the latest and updated some GPS drivers in the Library. Be sure to pull the latest code and check http://apm.tridgell.net/ for the status of each build run against the SIL sim server.
Update r3:
I pushed a version on to GIT that addresses a number of issues.
- the low speed GPS XY calculations were incorrect and have been fixed
- Nav_Rate I term has been removed in loiter control - it's too easy to get two iterms working out of phase
- A second derivative has been added to Roll and Pitch. I found it removed wobbles nicely - Can be adjusted in the planner as STAB_D with a default of .25 (just enough)
- Smoothing has been applied to the motor commands in a way that really quiets down the alt hold pulsing without much effect on latency
- Yaw now has a dynamic constraint and I've upped the yaw gain.
- The motors output now have an LP filter on them so that the accelerate just a tad slower than the deceleration. This is a test to see if it helps big Octo's and Hexa's
- The Rate_I term is now zero'd for first five seconds after takeoff to keep balance.
- Loiter gains are lightened up a bit
- Nav_Rate_P is lower to remove back and forth sped related hunting in loiter
- Compass is enabled by default
- New I2C Library now included which should solve I2C related lockouts
- optflow is still a work in progress.
Update R4:
This update is based on flights today in a very windy environment.
It occurred to me that we're handling the WP nav I terms incorrectly and I reworked the WP navigation to share the same I terms from the Loiter. Even though they use different error input, etc, they turn out to both deal with wind in the same way. I have not Flown WPs with this new code, but heavily tested it in the sim and It's really rocking in hard wind. Transitions from Loiter flight and Nav flight are very smooth. Please let me know if you have luck.
Update R5:
This is a quick patch based on a bad crash Marco had. My theory was an I term that built up during wind that needed to be reset, but wasn't. It's a corner case but It bit Marco pretty bad. Please re-pull if you have R4 running to go to R5. And please, please be careful. This is alpha code not for general testing, but for development. Don't fly it on anything you would feel bad about crashing.
Jason
Update R6:
Update R7:
Added an auto-land timer for RTL. If you don't change modes for 20s after the copter arrives at home, it will begin to auto-land. If you have failsafe and no GPS, you will immediately begin auto-landing.Update R8:
Minor tweaks and cleanup
Update R9:
Made climb rate controller for landing universal for all altitude changes
Update R10:
Updated Loiter controller - Works great in the sim, thanks Afernan.
Thanks,
Jason
Replies
HIL compiling error in r3 fixed
Following the clue of the error, I´ve seen that the definition of init_compass() and init_optflow() was done in "Sensors.pde" but only inside "if HIL_MODE != HIL_MODE_ATTITUDE" (so outside HIL mode).
So I´ve added the definitions after the endif (line 115), and now it compiles correctly.
Attached is the corrected "sensors.pde" file
Best
Angel
sensors.pde
Today i've found a little time to test the loiter of the 2.1.1r3 Alpha release with my octo.
Little wind at the fly field, some very very fast pid tuning and this is my result.
After one minute i've some drift to the left, about 10/12 meters do i think because i've no good precision with my gps (without battery backup at the moment).
Anyway no circle, for me this mode now is pretty good... "LOITER P -> 0,4" and "NAV P -> 0,8".
I've a little slow bouncing oscillation in the yaw, but I'm sure it's just a wrong tuning, too fast because here is too cold and I left to home my battery chargers (LOL).
IMHO Jason did a great work because with the simulator the loiter is perfect when the sensor are emulated by the PC, so that GPS did not miss a shot and there's no vibrations that may interfere with gyro and accelerometers.
In reality now the errors are caused only by inaccurate operation inside all the sensors, but the loiter routine in my opinion is pretty much perfect, and for this now i really need APM2... :-))
My video does not say much, so i'm waiting your tests under less permissive wheather condition.
Bests,
Marco
So... Hexa is loaded with the latest git code 2.1.1r3 with my showleds. Gonna have some soup to give me some courage and then I'll give it a go (it's dark here now, but the leds negate that).
Just had the hexa on alt_hold for about a minute in my hand and it seemed to behave. Let's hope for the best :-)
Hello.
In my quad project, I'm using a black plastic dome to cover the electronics. I already modified the code to use AN6 and AN7 as "clones" of the status LEDs on the OILPAN, so I can mount them at the dome (with a black dome I can't see the LEDs on the board). I've tested, everything working fine, I had a little issue with the armed motors LED not beeing solid, but then I found the temporary hack at the motors.pde.
However, I would like to change the LED behavior to strobe at a small frequency when not armed and higher frequency when armed. This would give my quad a nice strobe and a chance to watch the motors status. I was thinking on making the following changes to the code, but would like to know first if this would ruin the loops or if it's ok to use it, since I'll be using the user 50hz loop.
This would be the changes :
UserCode.pde
void userhook_50Hz()
{
// put your 50Hz code here
update_strobe();
}
config.h – linha 107
# define STROBE 58 //an4 near the buzzer an5
# define STROBE_LED ENABLED
system.pde – linha 124
pinMode(STROBE, OUTPUT); // STROBE status LED EXTERNO
digitalWrite(STROBE, LED_OFF);
leds.pde
...
#if STROBE_LED == ENABLED // funcao de strobe em an4 implementada por Rui
static void update_strobe(void)
{
static byte strobe_count=0;
static bool strobe_flash_armed = true;
static bool strobe_flash_notarmed = true;
if(motor_armed == true)
{
if (strobe_count==50)
strobe_count=0;
if ((strobe_count%2)==0 && strobe_count<=14)
{
if (strobe_flash_armed)
{
digitalWrite(STROBE, LED_ON);
}
else
{
digitalWrite(STROBE,LED_OFF);
}
strobe_flash_armed=!strobe_flash_armed;
}
strobe_count++;
}
else
{
if (strobe_count==200)
strobe_count=0;
if((strobe_count%50)==0)
{
if (strobe_flash_notarmed)
{
digitalWrite(STROBE, LED_ON);
}
else
{
digitalWrite(STROBE, LED_OFF);
}
strobe_flash_notarmed=!strobe_flash_notarmed;
}
strobe_count++;
}
}
#endif
If it's ok for me to implement, please let me know, so I can make the changes to the files. I'm asking your opinion since I'm not totally familiar with the code.
Just returning to the project after a short break. Loaded the new firmware and setting up again for a new quad.
All motors are plugged correctly but I have a reversed Elevator. The monitor in setup shows it correctly (Green bar rising as I push forward)
I've got a feeling I'm doing something daft so just to check.
This is a Quad in X config.
Motor 1 is top right Anti Clockwise
Motor 2 is bottom left Anti Clockwise
Motor 3 is Top Left Clockwise
Motor 4 is Bottom Right Clockwise
Front is the opposite end to the servo connectors
I had been following this thread and all previous anxiously waiting for some good news as my two APM-1 boards with oil pan and shields are waiting for a solid performance. During this time I had tried Wookong M so shifted everything on DJI.
Despite the fact that DJI can do GPS hold practically in less than in 1/3 meters (even better if frame and motors are well tuned), It is also important to note that for most of the frames that I test DJI has no drift indoors even when there is no GPS. So before the loiter I think in windless condition
1. The copter should hold its position without GPS for fairly good amount of time without drift. Keep in mind DJI needs no training (leveling and trimming) flights.
2. Baro should work as accurately as if its a sonar which works for DJI
3. Flying experience in stabilized mode should be pretty good. So that the pilot should have real feel of good command and smoothness in performance.
I think the basic flying should be improved first before jumping on to the GPS based cruise. I am going to get DJI GCS tomorrow and shall compare its performance with APM.
Its not a criticism its just my opinion how the community should proceed. In the meantime I am thinking of porting the open source libraries for GPS to ARM32F4 using ST Discovery kit(only for 12$). Someone else may take lead in the idea as I shall start this work in few days..
By the way can someone show the performance of APM2. I am really interested If this thing reaches the performance of the other professional solutions. Although I am not practically contributing in the development task but I think users like me are providing support by buying the hardware (which keeps this DIY system going), providing support on giving feed back of bugs and performance.
I am happy that developers do regard opinion of people like me
This is my new video about the loiter with "ArduCopter V2.1.1r3 Alpha (HIL)" with "AeroSim RC", first recorded for better post video capture.
For testing the drift i move sometime only the yaw for a continuous rotation.
The Idea of making the copter rise and RTL in case of failsave is my idea.
I've spent weeks on writing emails to the programmers and posting in the forum, but the only thing I've got were bad words and that this behaviour wouldn't be allowed in Germany and so on...
Then I changed platform from MK to Arducopter and now they present their great new idea.
...just my 2 cents...
Does this version offer the CLI: Setup->esc (ESC calibration) modus?
The firmware: 2.1.0 alpha I flashed today doesn't offer this option any more. So I had to calibrate them manually.
Kai
-
8
-
9
-
10
-
11
-
12
of 14 Next