ArduCopter 3.0.1 has been released and is now available in the Mission Planner, firmware.diydrones.com, GitHub and the new Downloads Area.
Warning #1: Compass calibration and reducing interference is far more important than with 2.9.1b
Warning #2: GPS glitches can cause sudden and aggressive position changes while in loiter mode. You may wish to reduce the Loiter PID P to 0.5 (from 1.0) to reduce aggressiveness (see image below of where this gain can be found in mission planner).
Warning #3: optical flow is not supported but will be back in the next release (AC-3.0.2 or AC-3.1.0).
Warning #4: loiter turns does not maintain altitude. This bug will be fixed in AC-3.0.2.
Warning #5: This release has only been lightly tested on Traditional Helicopters.
Improvements over 2.9.1b include:
- Inertial Navigation for Loiter and Auto meaning much more accurate control (Randy,Leonard,JonathanC)
- 3D navigation controller follows straight lines in all dimensions between waypoints (Leonard,Randy)
WPNAV_SPEED, WPNAV_SPEED_UP, WPNAV_SPEED_DN, WPNAV_ACCEL allows configuring speeds and acceleration during missions
- "compassmot" to compensate for interference on compass from the pdb, motors, ESCs and battery. (Randy,JonathanC) (Set-up video here)
- Safety improvements:
- simple Tin Can shaped Geo Fence
- pre-arm checks to ensure all calibration has been performed before arming (can be disabled by setting ARMING_CHECK to zero). (video description here)
- GPS failsafe - switches to LAND if GPS is lost for 5 seconds
- stability patch improvements to stop rapid climbs in very overpowered or overtuned copters
- Circle mode improvements including "panorama" when CIRCLE_RADIUS set to zero (Randy,Leonard)
- SONAR_GAIN parameter added to allow better tuning of sonar surface tracking
- CH8 auxiliary switch (same features as CH7)
- works on PX4 (some minor features still not available) (Tridge,PatH)
How to upgrade:
1. Make sure you are using Mission Planner 1.2.59 or newer (get it here)
2. Click on the MissionPlanner's Hardware, Install Firmware screen. The version numbers should appear as "ArduCopter-3.0.1", then click the appropriate frame icon and it should upgrade as per usual.
3. Reduce the Loiter and Alt Hold PIDs if you have modified them from the defaults. The modified PID values for the 3DR frame can be seen in the image below.
Note: Nav parameters have been combined with Loiter so do not be concerned if you can't find them.
4. Although not directly related to this release, if you purchased an APM prior to March of 2013, update your PPM encoder to the latest firmware (instructions here).
5. Try out the new version in stabilize mode first, then alt-hold, then loiter and finally RTL and Auto.
Numerous How-To videos are available:
Special Thanks to Marco, DaveC and the large number of testers on the pre-release thread who put their copters at risk during the extended testing period. Some of their videos can be found here, here, here, here, here and here. Thanks also to MichaelO for the MP changes required for this release.
All feedback welcome. Please put your questions, comments (good and bad!) below.
Replies
A Question about planning a mission.
Is it possible planning a mission on a why the turns are smooth, At this moment it is for me only possible the quadcopter stops at a wp, makes a turn and flies to the next wp.
gr.
Dick Gerritsen
Dutch mountains,
the Netherlands
Question about the 3dr external compass with compas
When you cut the trace on the apm board and power it on, with no gps connected, should the deg heading stay on 0?
I want to make sure that the cut of the trace on the apm 2.5 is properly done, is there a way to test this?
With all possibilities the APM is currently offering us, Measures for GPS glitch/loss can be quite complicated as the multi may be in various scenario's. Personally, I think the following options (if even possible?) will cover most scenario's in case of GPS glich/loss.
(10) - When in flight mode not GPS depended; Do Nothing
- When changing flight mode which is GPS depended and we have no GPS (or even too few sats only 2 or 3), do not go into flight mode (ie, pre check GPS Nsat)
- When in flight mode GPS depended and a GPS glitch/loss occurs, enter alt hold in simple mode by default and make a visible/audible sign to the pilot. (i vote for 360 yaw but not sure if the multi gets into trouble if it is traveling fast). After 3 to 4 seconds, execute parameter which is set by the pilot (land, stabilize, alt hold, etc).
- If GPS returns with enough sats, the multi will be landed or in a flight mode not GPS depended. So from here we can start over (goto 10)
Just my thoughts! Any measures to make the APM more safe and smartypants are building blocks to become the best flight controller :-)
I got a gps cn-06 v2 from a clone company (rctimer) and had problems with loiter and RTL
After upgrading the gps with the 3dr script it seems much beter, script removes unnecessary data and updates the transfer rate.
But the feeling with the glitches stays in my head, any sign when we can we test the gps fix version?
Hi Randy,
I was looking at the 3.1.0-rc2 code, to see how GPS glitch were handled, and I notice several things :
- gps_hdop_good is not check when entering in a mode that need GPS
- when copter is already in a mode that need GPS, where's no check about gps_hdop_good, so gps glitch problem can still occurs
- to handle previous point, we can configure GPS failsafe, but this mode only LAND the copter, there's no other option, like ALT_HOLD, and gps_hdop_good is not handled.
I was wondering about modifying those files to test gps_hdop_good before entering in a mode that need GPS
- Adding gps_hdop_good to system.pde method GPS_ok()
g_gps != NULL && ap.home_is_set && g_gps->status() == GPS::GPS_OK_FIX_3D && g_gps->hdop <= g.gps_hdop_good
- Impact on motors.pde, method arm_checks :
mode_requires_GPS(control_mode) && !GPS_ok()
But to handle gps glitch when copter is already in mode that need GPS, I've modified control_modes.pde method read_control_switch(), but I'me not sure it's the right place
Hi devs and generally clever people,
Just posting here as I have been one of several people with very similar-sounding crashes recently in RTL or Loiter mode. There have been several threads but none have had the attention of any of the devs or other super-knowledgeable people who hang out on this thread so I just wanted to try and get some expert input.
Here is my thread. In summary: copter flew well in all modes including Loiter and RTL, even on quite a windy day. Flying again two days later, much calmer weather, I seemingly lost control of the flight mode and eventually triggered RTL by switching off the Tx. RTL was triggered successfully but did not behave right: it did not climb to RTL altitude; it applied maximum pitch and throttle and flew at full speed (faster than the configured navigation speed) to the ground, destroying itself and nearly me. The GPS and other values from the log indicate that it knew it was getting further away from where it needed to be. There was no evidence of toilet-bowling or other compass related issues, or GPS glitches; the logs show the copter going exactly where it did in reality, and previously it had flown well.
Then there is this thread. Although that user's copter was by his own admission not well set up the logs show the same story of RTL requesting a massive pitch / roll and throttle input resulting in speeds far in excess of what it should try and achieve and ultimately a crash.
Then there has just been this one posted. Hard to be clear from the very short section of the log so this one could just be a GPS glitch but once again a similar massive input requested in Loiter mode this time.
Then there is this thread which has no logs posted unfortunately but describes a similar problem of an uncommanded flight, again in a straight line rather than the toilet bowling of compass problems.
I've spent quite a bit of time trying to figure out what went wrong with my flight and have posted logs and selected relevant graphs on my thread. I am clearly not alone in having this problem. I know that Arducopter can be and normally is superb, but there is, to my eyes, something going on here that is NOT answered by the "same old" vibration, compassmot, etc questions. I'd really, really, appreciate it if somebody could take a look.
Cheers,
Harry
fw ac3.01
apm2.6
about followme mode,
seems have default altitude, how to maintain current altitude when trigger followme mode? any parameter setting?
thanks
Hi All, I am new to APM 2.6 (with external GPS/Compass) and have initially installed firmware 3.0.1 which worked ok after the required setup of frame type, live compass, accelerometer and radio calibration. I then re-wired and changed the multirotor setup as compassmot resulted in 200% vs current (using the 3DR PM). After this the compassmot was 4% and vibration is around 2 with a few peaks to 2.8.
Did some test flights after auto trim and stabilize is good. Loiter however still has some drift (max 2m around target). I tested with auto declination and fixed using the website but no real change. Wind conditions were very calm. The multirotor also showed a few twitches during loiter which somewhat freaked me out :p
I then decided to install the 3.1-rc2 firmware with a small adjustment in radio.pde to swap my Turnigy 9x channel 5 to 6. This way I can use the 3-way switch for flight modes as I'm using a PPM receiver. Thanks to RickP for this!!
The firmware installation worked fine using the modified Arduino IDE but now the rotors spin after arming with trottle 0 (stick down). Re-calibrating radio and ESC gives the same result. The twitches during loiter also seem more aggressive. I have attached the last test flight log for analysis. See pitch twitch around 12 min followed by my panic reaction :p
Can anyone give me some direction where to fine tune the small loiter drift, twitches and motor spin-up with arming only? Overall I'm very pleased with the flight behavior of 3.1-rc2.
My Setup;
- Tarot Iron Man 650 Quad
- T-Motor 4008-12 600kv
- T-Motor T-40A ESC
- CF 15x4 props
Rgds,
Dimitri
2013-09-25 18-33 1.log
Hi randy, I loaded ArduCopter 3.1-rc2 on my Talon Hex, it flew like mushy dog poo, then I swapped the cheap plastic props for some Rctimer CF 9 x 5 and WOW, 3.1-rc2 flies the Hex beautifully now, had no idea CF props could make that much difference.
I am using a not yet release ublox based Rctimer CN06 PLus GPS and Mag
Boring video of silky smooth loiter in about 10 kt winds just above a 30 meter tree.
Some log graphs from that test flight, I start off surrounded by tall trees, I do connect Lipo and wait 5 minutes to allow GPS and Baro to stabilize BEFORE Flying
Thanks for all the effort you and the Dev team has put into this release, words fail to describe just how good it really is.
Hi Randy,
I'd like to clarify three things in fw 3.1 rc2.
1. Here's my current settings:
MOT_TCRV_MAXPCT: 93 - Options: 20 80 - Set to the lowest pwm position that produces the maximum thrust of the motors. Most motors produce maximum thrust below the maximum pwm value that they accept.
Question: Should I limit this number (93) up to 80 only?
2. And here's my current settings for GPS HDOP.
GPS_HDOP_GOOD: 150 Options: 100 900 - GPS Hdop value below which represent a good position. Used for pre-arm checks.
Question: Is 150 equal to 1.5 as displayed in my MP?
3. Lastly here's my settings for my compass.
My current settings: COMPASS_EXTERNAL: 0 Options: 0: Internal, 1: External
- Configure compass so it is attached externally. This is auto-detected on PX4, but must be set correctly on an APM2. Set to 1 if the compass is externally connected. When externally connected the COMPASS_ORIENT option operates independently of the AHRS_ORIENTATION board orientation option.
Question: Should I set this to 1 since I'm using an external compass for may amp 2.6 board? If yes, should I also change the COMPASS_ORIENT parameter (Which is currently set to 8 - Roll180)?
thanks.
-
39
-
40
-
41
-
42
-
43
of 84 Next