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
Hello Eseban. Check point 11 on page one of the thread.
Esteban,
Compassmot must be done through the ground station in AC3.2 even for pixhawk users. We needed to remove the cli for the APM2 (for space reasons). The MAVLink version had to be quite different from the older cli version (in terms of how it communicated with the user) and I didn't think we should maintain two versions of compassmot when one would do.
I think we may have changed the behaviour at some point (before AC3.1.5) so that it doesn't show a warning or switch to RTL when the vehicle is disarmed. I'm pretty sure that AC3.1.5 acts the same as AC3.2 but in any case, to test the failsafe you really need to arm the vehicle in stabilize (or some other flight mode), raise the throttle and then turn off the transmitter. Then it should switch to RTL. Note that there's no need to connect a battery during this test.
MarkM,
(we've run out of depth so replying here).
So what you're noticing there with the flight modes is the way that it's intended to work. It's basically ignoring any changes in the flight mode or ch7/ch8 switches while the failsafe is happening. Once the failsafe clears it's begins where it left off. So if you haven't moved the flight mode switch, then it doesn't see any change in the flight mode switch and it leaves the flight mode as it is (which is RTL). If you've changed the flight mode switch while the TX was off then when it's back on again, the flight mode pwm value will be different than it was the moment the failsafe started, it will see that difference and change the mode.
This is somewhat explained on the wiki when it says this:
Anway, I'll review the failsafe page and add some info at least regarding the newer receivers that stop sending signals instead of dragging the throttle low.
Randy, could you clarify if the "Warning to FRSky receiver users and users of other receivers that modify channel 5 during a failsafe event" section is still relevan? So far what I have observed is that it is enough to setup thr. failsafe in MP and leave my x8r to output default "0" value on all channels. However, this contradicts the section of the failsafe wiki I have quoted above. does AC code ignores all other channels as soon as throttle goes below failsafe threshold? thank you!
Artem,
Yes, you're right. That section is not correct anymore. AC ignores all channels when it's in failsafe including flight mode and ch7/ch8 switches.
It's also completely missing a section to explain how to test receivers that don't pull the throttle low but instead simply stop sending signals... although this won't help Esteban.
I'll rework that page a bit.
Thank you, according to the manual default failsafe for x8r is to send 0 to all channels.This would be nice to see if I got everything correct. So far I've only tested throttle failsafe 4-5 times by turning off Taranis, never actually lost my signal.
Is DRM back?
Q1) Has anybody flown RC11 with a hex? Please respond if you have... I was helping a friend with his brand new hex which would fly away whenever a GPS dependent mode was engaged. (lat long on the FPV screen were exactly right with 8 sats) in stabilize or alt hold all is well. in Position, it would not hold altitude... way over powered so I think that it is out of deadband... I don't have his logs...but again the question, any other fly aways with a hex on RC11?
But here is the interesting part... I looked through the configs and noticed that the AHRS_EKF_Use option is not available on his hex... we confirmed that it is there along with a bunch of other EKF options are available on my Quad. I went home and loaded 3.2RC11 quad frame on a spare pixhawk clone... and none of the AHRS EKF options show up. screen shot below.
Q2) is there a setting or procedure somewhere to get this to show up in Mission Planner or is this DRM version 2? (please say it isn't so)
screen shot of configs from clone: 3.2 RC11
Thanks for your thoughs
Brandon, thanks for checking... the screenshot below is from my Quad (same PC, same mission planner, 3DR Pixhawk instead of a clone this time)... and the EKF option is there.
What chain of events makes the EKF option show up or not show up?
Hmm that was the key to the issue above... yeah the CLI is there... and it shows 3.1.5. (EKF introduced in 3.2) Reflashed 3.2 RC11 and all is well...
Brandon thank you.
If for any reason, MP tried to load APM code onto a Pixhawk-class board, it most certainly would not run at all. That would probably be best-case scenario. Worst case, it would probably brick it. So I don't think that it could be that MP is getting confused and uploading the wrong code to a Pixhawk-class. You'd never get so far as to see the parameters list in MP, because it wouldn't even boot.
However, if the cloners stuffed an APM into a Pixhawk case... yeah, that would be interesting wouldn't it?
FWIW, I have seen nothing in the source code which would indicate any attempt at DRM. If there is, it would have to be buried deep in the HAL layers, which I guess is possible but... Seems a bit tinfoil hat-ish to me.
-
87
-
88
-
89
-
90
-
91
of 262 Next