Warning #1: PX4/Pixhawk users upgrading from AC3.1.5 (or earlier) may need to re-do their compass and accelerometer calibration because AC3.2 also uses the backup compass and accels. Pre-arm checks have been added to ensure this has been done.
Warning #2: on the APM2.x the logs must be downloaded using MAVlink instead of the terminal.
AC3.2-rc14 is now available for BetaTesters through the mission planner’s Beta Firmwares link. The full release notes can be found in ReleaseNotes.txt and changes from -rc13 can be seen below.
Feel free to raise issues found during testing on this discussion or in the new support section in the APM Forum.
It’s a big release with “the onion” restructure and a bunch of new features (including these 57 closed items) so we need to re-test almost everything including all flight modes, all mission commands and all the new features. Marco and I will be maintaining (and adding to) this testing list. Issues reported will first be checked by Jonathan, Marco and I and then confirmed bugs/issues will be put on the github issues list (and then hopefully fixed).
Thanks especially to the beta testers who put their copters at risk testing each release. Enjoy!
Changes from 3.2-rc13
1) Safety Features:
a) fail to arm if second gyro calibration fails (can be disabled with ARMING_CHECK)
2) Bug fixes:
a) DCM-check to require one continuous second of bad heading before triggering LAND
b) I2C bug that could lead to Pixhawk freezing up if I2C bus is noisy
c) reset DCM and EKF gyro bias estimates after gyro calibration (DCM heading could drift after takeoff due to sudden change in gyro values)
d) use primary GPS for LED status (instead of always using first GPS)
Replies
1. I think it would be safe, since 3.1.5 is a stable release
2. Check out logs for the changes from 3.1.5 to 3.2. Regarding pos hold, equivalent flight mode on 3.1.5 exists, which is Position, I used that when I am on 3.1.5 too, and it is definitely great to have that mode, but requires GPS lock of course.
3, I believe changing from 1 build to another requires recalibration of compass as well as getting compensation for Compassmot, etc...
However, I think that if you saved your previous configuration when you are in 3.1.5, you might be able to just load the saved parameters to your aircraft, assuming you did not change any thing on the frame or position of the parts of the aircraft.
Currently I am on 3.2 rc12, but I still did not try flying with this due to reports on stability of the build. might as well get back to 3.1.5 and just reload my previously saved configs to skip the recalibration part. :) Hope idea this works
When reloading parameters you just need to be a bit careful to not blindly reload all parameters because technically there's not enough space in the eeprom to hold a unique, non-default value for each parameter.
If you set a param to it's default value then it doesn't take up an eeprom slot.
I've never seen a case of the eeprom filling up and I don't want to create fear where it's not justified but I'd recommend trying to reduce the list a bit from the full list.
You can tell if your eeprom is full because you parameter will revert to their old values when the board is rebooted.
thanks for the tip Randy, I will consider it. By the way, is writing on EEPROM permanent? I mean if I filled it up in time, is there a way that I can still modify the contents i have written on it?
Hi Randy,
I just found some props spinning when copter disarmed, and could not understand why. I am flying an X8, APM2.5.
Found out I accidentally misconfigured gimbal to use RC7 and RC8, which caused the ch 7 and 8 to send a signal to the motors.
Might it be an idea in future builds to block inadvertent usage or block override of the channels by anything else if used by motors in case of hex or octa?
Thanks for the hard work.
//Ed
Ed,
Thanks for the reports, I thought we'd added that safety feature in AC3.2 already so I'll have a look.
I just connected my receiver wrong, my ground was in the 5v pin and the 5v was in the signal pin, what could I have damaged? the quad seems to be flying at least in STAB and Alt hold in my living room but the camera switch and the gimbal are not working
I'd like to THANK the Developers for giving me the ability to get this footage at The Zombie Run at the Guardian Disaster Center In Perry Georgia https://www.youtube.com/watch?v=7wNAc3v8JGU
Pomaroli,
I tested the back-flips in the simulator with ACRO_TRAINING set to 1 and using the same ACRO_RP_P and ATC_RATE_RP_MAX and ATC_RATE_Y_MAX as appeared in your logs. I wasn't able to make the [simulated] vehicle fail while doing back-flips even if they occured soon after rolls. I also tested recovering in stabilize mode while the vehicle was inverted. The only thing I found is that with ACRO_TRAINING = 1 (which automatically levels the vehicle if you remove your hands from the stick) the backflips are quite messy because it starts auto-leveling the roll while the vehicle is inverted. So as the vehicle becomes inverted during the back-flip, the roll suddenly becomes -180deg and it starts trying to bring that back to zero. This makes the vehicle start rolling instead of cleaning completing the flip. During rolls this doesn't happen because the pitch is unaffected by the roll.
So it was all a bit messy but nothing catastrophic happened in the simulator.
Randy it is not out of place because this issue is noticable since 3.2.
Under 3.1.5 no issue
Hi Randy, no problem to me i'm reading all posts, especially yours.
so cool you found out something, thanks for your efforts.
It sounds like the issue i was having. To do flip/rolls i normally give shortly pitch and when the vehicle is inverted i give roll input.
between pitch and roll inputs there is surely a short time frame were no pilot inputs are made and the trainer mode is taking over trying to bring the vehicle level.
if i'm doing only flips without rolls, i give only a short pitch input, so there is also a short time frames where no pilot inputs are made and the trainer is taking over.
What i observed is that if the vehicle is inverted and the trainer is taking over and then a pilot input is made then it looses control. probably because there are 2 objectives, pilot input and trainer ?
i've avoided to do some flips since last crash because of a new FPV equipment. FPV it's very funny too.
Let's try to see what happens in the simlulator first.
Concerning the other 2 cases :
1. CH6 knob and NAV Speed correction released with rc13 -> it's perfect. If Rc is set to off it falls to minimum value. If Rc is set to on it is overtaking CH6 value.
2. Autotune is still making strange things, but i'm not sure if the issue is mechanical of type nature.
-
81
-
82
-
83
-
84
-
85
of 373 Next