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
this has worked really well for me to eliminate vibrations - all my FC's are mounted with it http://www.amazon.com/Kyosho-Z8006-Vibration-Absorption-Sheet/dp/B0...
i just reviewed the link posted by bill, thanks.
i'm using Graupner Pad 2904 (http://www.eflight.ch/pi/Graupner-Schaumstoff.html)
This foam is working pretty good but the problem is that it is to thin (2mm)
The test's i've done so far have shown, that 4mm is a good thikness to go.
Therfore i will use two of them in stack for each corner placing them square to make the force's impact most evenly.
from what i was reading in the other post, the vibrations have a deep impact for althold, so i'm curious to see the result.
Rob thanks, you guys know what you're talking about. This all you see on looking on the logs, great. I'm realliy spending a lot of time balancing the props and i guess you're on the right track. therefore my idea was to change the foam to slightly softer. But it's always a balancing act, to soft foam will cause more vibrations as it will reduce. So we could says "the foam should be so hard as possible, so soft as needed"
I have some older logs with softer Foam, the result was less peak vibration and more static vibration "noise". Therfore my decision was to go for the harder foam as the overall impact is lower.
But now i have a new point of view and must admit this should be reconsidered.
as wrote above i would try to use a foam between the hard which is mounted and the soft i was using last time.
Another question what is the real impact to ALTHold modus ? are the noticable pulsing frequencies really coming from the vibrations as supposed by Randy ?
Hi Randy,
I experience a bug (or something) last Saturday while my octo was flying an auto mission. I was running on the 3.2rc12.
I have Channel 5 mapped on a 3 pos switch (Stab, Alt Hold, Loiter), and programmed Channel 8 for auto. I took off in Stab and switch to LOITER to gain height before switch channel 8 to AUTO. The mission was planned to map a 70m sand pile so I had no visual once it goes behind it. I was also expecting RC Failsure to trigger. True enough it did.
What happened was strange. The copter continued its mission for about 4 to 5 secs on failsafe before it when to LOITER mode. It stayed in LOITER and I had to toggle channel 8 to get it back in AUTO (failsafe message when off).
I am thinking that this is a channel issue.
Attached are the logs.
Thanks in advance.
Murdanny.
37.BIN
Murdanny,
Unfortunately the RCIN message is enabled by the LOG_BITMASK so it's difficult to see exactly what happened with the RC input. Could you set the LOG_BITMASK to NearlyAll?
It looks like there were 5 separate radio failsafe events in a row with the first one starting 69seconds into the mission and the last one cleared 108 seconds into the mission (i.e. 39 seconds later). It was 0.4 seconds after the last one cleared that the vehicle switched to Loiter mode. That number is slightly suspicious because it's exactly twice the debounce time for the ch5 switch.
Any chance you could do a bench test for us? Try doing this with the battery disconnected but the flight controller connected to the mission planner with a USB cable:
1. arm the vehicle in AltHold, raise throttle above 60%
2. switch to Loiter mode with the ch5 switch
3. switch to Auto with the ch8 switch
4. turn off the transmitter and wait for 5 seconds
5. turn on the transmitter and wait for 5 seconds
6. check if the vehicle has switch to loiter by looking at the MP (and post a log here).
Hi Randy,
Okay. Attached is the logs that i bench tested according to your instructions.
Took me a while because I was wondering why I couldn't arm, just to find out it was actually a battery failsafe. Side track, we can't disable the battery failsafe now?
It did not went to loiter.
I hope the logs helps.
Murdanny.
45.BIN
Murdanny,
Ok, as you say, in this test it worked a-ok. During the radio failsafe only channel 3 moves. ch8 seem unaffected by the failsafe. The ch8 high and low positions seem fine as well, with high being well above 1800 and low being well below 1200.
The only thing that stands out is there is a fair bit of jitter in the pwm signals on all channels except #7. I have no idea if this is related. It could be a complete coincidence.
There was also a comment earlier today that having the maximum for a channel over 2000 could cause interference on the next channel but I have not yet tested this.
is this for ppm (<2k) or for sbus too? Also, on my x8r setup I use channels 1-8 on the sbus and channels 9-16 on the x8r pwm outputs (x8r bind case 4...if I am not mistaken) and on my dtfuhf setup I output channels 1-8 via ppm and the rest on the available pwm outputs. In both cases I use full taranis range 982-2006, should I be concerned even though I haven't had any problems yet(since January)?
Artem,
FrSky only. SBUS should be fine.
-
63
-
64
-
65
-
66
-
67
of 373 Next