After months of testing AC3.1 is finally available in the Mission Planner and GitHub.
Warning #1: If the vehicle is left landed (but armed) while in AltHold or Loiter mode for more than a few seconds, the vehicle may suddenly jump into the air the moment the pilot raises the throttle above zero. The reason is the baro altitude may fall while the vehicle is sitting on the ground. In AC3.2 this bug is fixed because we reset the target before take-off.
Warning #2: Motors will spin (slowly) by default as soon as the copter is armed! You can switch this feature off by setting the MOT_SPIN_ARMED parameter to zero.
Warning #3: if you see "Bad Gyro" on the HUD then you may have a blown 3.3V regulator. See this thread for details.
Warning #4: if you use a sonar set the SONAR_GAIN parameter to 0.8 or lower
Warning #5: Trad Heli users should now connect their main rotor ESC to APM's RC8 output
Warning #6: Trad Heli BUG causes loss of collective control in ACRO mode if swash type set to flybarred (i.e. not flybarless). Will be fixed in AC3.2.
The major improvements over AC3.0.1 are (full list here):
1. Pixhawk support (Tridge & PX4 development team)
2. Autotune of Roll and Pitch gains (Leonard/Randy)
3. Drift mode (Jason)
4. Improved Acro (Rob/Leonard) and new Sport mode (Leonard)
5. Arming, Take-off, Land in Loiter or AltHold
6. TradHeli improvements (Rob) including:
a) support for direct drive tail rotors
b) smoother ramp-up of main rotor
c) reduced collective for better control in stabilize mode (STAB_COL_MIN, STAB_COL_MAX params)
7. Support for SingleCopter (Bill King)
8. Performance improvements resolve AltHold troubles for Hexa & Octacopters
9. Safety Improvements:
a) GPS Glitch detection (Randy)
b) Motors spin when armed (Jonathan Challinger)
c) crash detector shuts off motors if copter flipped for 2secs
d) batt failsafe option to RTL instead of LAND, gps failsafe option to trigger AltHold instead of Land
e) more pre-arm checks of inertial nav speed,
10. Bug fixes:
a) optical flow working again (although performance is still not great because not integrated with inertial navigation)
b) ROI working (use DO_SET_ROI command)
How to upgrade:
Click on the MissionPlanner's Initial Setup >> Install Firmware screen. The version numbers should appear as "ArduCopter-3.1", then click the appropriate frame icon and it should upgrade as per usual.
Special thanks to Marco and the many beta testers on the AC3.0.1 thread who put their copters at risk during the testing of this new version and uncovered many problems so that you don't have to! Here are some of their videos: loiter in wind, patio sonar, autotune, autotune2, roi, beach, acro, vrbrain, tricopter, train spotting, radio failsafe, the tree, double loiter
If you haven't seen it recently, please check out the ArduCopter wiki.
Feel free to post comments below and we're going to use the new APM Forum for support issues so please post your support requests there.
Replies
Ah - I didn't know - navigation was just reworked in 3.0.1 and I assume that it will stay like that for a while at least - I like quite a bit the way it works (I tried 2.9 and didn't like it), so I'm surprised to hear you're revamping. As far as I can tell (and by now I have many hours of auto flights) all works well except for the RTL climb phase. The unique thing for the RTL climb is the fact that the origin and destination are *exactly* one on top of each other (everything else has some slight deviations from perfect vertical).
Best,
Mihai
Mihai,
I've raised an issue to cover this issue and also had a quick look at the revamped RTL. I don't see any particular reason why it would twitch. It's a good point you raise about the origin and destination being exactly one on top of the other and it does have some special handling in the waypoint nav code for this situation. Anyway, I'll run it through the simulator at least to see if anything turns up and we can add it to the to-be-tested list for the AC3.2 release candidates.
https://github.com/diydrones/ardupilot/issues/970
Re the code re-vamp for AC3.2, internally it's a very big change but I don't think you'll notice a massive change in how the waypoint nav actually flies or at least nothing like the change we saw between 2.9 and 3.0.
another twitch reported here.
http://ardupilot.com/forum/viewtopic.php?t=7204&p=15143#p15143
I'm answering your question below (for some reason it doesn't let me answer the question under the question). My tune was done manually, as autotune was apparently enough to trigger the motors shut-down bug. Now that it has been solved, I may very well give autotune another try.
Best,
M.
Mihai, I just hope they've seen the whole scene before doing the re-vamp. If they've committed another "slip" again on this then that's a disaster. I might be wrong, so be prepare to be amaze. I'm afraid to take the risk on AC3.2 unless we've received only few bug/s.
By the way Mihai is your copter done in auto tune?
Hi Randy, Mihai & Jonathan,
I tested again the AC3.1.3-rc1 this morning. First I redo my auto tune sequence thinking that this cause it all. Auto tune gives a nice PID settings. It flies very well and responsive. But all of a sudden it twitches again! This time worse happened! luckily it landed in a tree and no one was hurt.
Strange because I'm in a loiter climbing slowly, I'm playing pitch/roll to check how it respond to stick input. (I'm at around 10-15m), then here comes the wind! not so strong wind maybe around 10knots, then suddenly it TWITCHES AGAIN! I switched back to Althold but I was out of control and it was too late. Luckily my quad crashes a single piece and goes back a piece. :D By the way I take-off into loiter.
I'm still downloading my logs. Post it here later.
I've attached here my parameters too you may want it to check them.
param-4-12-2014.param
Jay,
The issue you are facing is quite different from the stability patch bug that should be fixed with this AC3.1.3-rc1 release candidate. If this were the stability patch bug then the logs would continue beyond the moment that the copter lost control.
I think it may be possible for you to recreate the issue on the ground in stabilize mode with the propellers flipped over and rotated one position (so the copter pulls itself into the ground when throttle is raised). After doing this arm the copter and raise the throttle to 75% or so until the battery goes down below 10.2V (My guess is this will take 4 ~ 5 minutes). The pixhawk will then likely black-out like it did during your flight. I guess you'll need telemetry attached so that you can see the battery voltage on the mission planner and know when to stop the test. Please be careful not to destroy your lipo battery. You probably already know but you shouldn't run your battery down below 20%. My guess is that when your battery is at 10.2V it's already below 20% though so the test itself might be slightly risky.
The point of this test is to show that the issue is in the power supply not in the firmware. If it's possible to make the flight controller black out then that shows that it's being starved of power. Basically the flight controller needs to be the 'last man standing' so the motors should stop first or at least there should be so little power left in the motors that it can no longer fly all before the flight controller is shut down due to lack of power.
Also what frame are you using? it's not an IRIS is it?
Randy,
The battery that i've used is fresh (fully charged) this battery usually flies at around 7mins or even more. I think its a brownout issue. I mean it flies perfect then suddenly twitches and uncontrollable. That's what happen, as far as I understand about brownout it suddenly cut the power and your copter suddenly drops.
By the way I use a power module to power it up.
Jay,
I've had a look at the logs and it looks like a power issue (i.e. a brownout) because the logs simply stop recording while the vehicle is about 12m in the air. Now whenever we say "brownout" all we know is the logs stopped suddenly and from experience that's normally a power issue.
I've attached a graph of the battery voltage as well, it drops from 12.4V at the beginning to 10.2V at the end. I don't know if that's acceptable or if the battery was so low that the power module or BEC was unable to give the board the power it needed.
How are you powering the board and is it a PX4 or Pixhawk?
It's Randy and Leonard working on the restructure for 3.2.
I'll take a look at Jay's log in a bit.
-
55
-
56
-
57
-
58
-
59
of 106 Next