Copter-4.0.2 has been released as the official firmware for multicopters and traditional helicopters!
The changes vs 4.0.1 are in the ReleaseNotes and copied below:
- Bug Fixes:
a) AutoTune fix to restore original gains when AutoTune completes
b) MAVFTP stack size increased to 3k (fixes reboot when using MAVFTP)
c) IO CPU timing fix which reduces ESC sync issues
d) Current Alt frame always relative to home (RTL could return at wrong alt)
e) Circle mode pitch control direction fixed
f) EKF only uses world magnetic tables if COMPASS_SCALE is set
g) Logging reliability improvements especially for FRAM logs
h) PX4Flow driver probes all I2C ports on Hex Cubes
i) RangeFinders using PWM interface (like Garmin LidarLite) use RNGFNDx_OFFSET param
j) RC override fix when RC_OVERRIDE_TIME=-1 (allows disabling timeout when using joystick)
k) Spektrum receivers decoding fix for Pixracer
l) SpeedyBeeF5 probes all I2C ports for external baro
m) TradHeli attitude control parameter description fixes (does not affect flight)
a) GCS failsafe warning lights and tones
b) Rangefinder fallback support (both must have same _ORIENT)
The most important fixes are the top 2 bug fixes which could certainly cause crashes (although MAVFTP is not regularly used yet). We strongly recommend Copter-4.0.0/4.0.1 users upgrade to this new version.
As always thanks very much to our beta testers who put their vehicles at risk during testing and provided valuable feedback which helped us get these issues identified and fixed. Also thanks to the other devs and pro-users who helped out on the forums over the past few weeks!
Thanks @rmackay9 and team! Will get this on my three devFrames and report back. As soon as it decides to get warm enough here anyway. Next week by looks of forecast.
Newbie (and I mean absolute newbie) question. Can this be used to update a 3dr Solo green cube pixhawk 2.1 quadcopter, currently running 4.0.1?
Is there some danger in using sonar/rangefinder values, overriden by hand and with jumping values when the EK_ALT_SOURCE is set as 0-use Baro? In my new setup i’m using sonar value to give back some custom paremeters through frysky telemetry back to transmitter for my lua scripting. I’m waiting for new frame after crush with v4.0.1 firmware autotune, and i have some doubts if it will be safe.
So there is something else on the vehicle that is publishing distance-sensor messages? Or you’ve someone setup a rangefinder (by changing the RNGFNDx_ parameters) that isn’t really a range finder?
If it’s the former then it should be safe. AP will only consume mavlink distance-sensor messages if RNGFNDx_TYPE = 10:MAVlink.
If it’s the latter then it’s probably not safe because some flight modes like Loiter and AltHold will try and use the rangefinder to maintain an altitude above the terrain.
Copter 4.0.2 testing and success.
We set up a refurbished old Quad X8 with AC 4.0.2 and initial parameters based on the new Tuning Guide and everything is going well on the first flight. Ground-based tests showed no issues. Flight tests in Stabilize, Alt Hold and Loiter have been good without any further tuning yet.
Now we will move onto Autotune and re-examine logs.
Tarot 650 quad frame, Pixhawk, 13"x5.5 RC Timer props, 8 Turnigy 390kv motors, 8 Turnigy red 40amp ESCs (basic PWM), 2 x 3cell 5200mah Lipos in series for 6 cell.
No telemetry or any additional devices fitted at this stage.
Great, thanks for the feedback!
Yes, I think so. If Copter-4.0.1 is on the green cube then I think it would be a good idea to upgrade to this new version.
AC: 4.0.2 Chibios
Frame: Quad Q
FC: Cube Black
Could somebody help me to find the reasons behind quite large difference between ATT.YawDes and ATT.Yaw sometimes ranging 5 degrees both directions - starting at 525.038 seconds.
Video shows camera panning both ways.
Vibrations are <10 on all axis.
thanks in advance
Configuration is: i have ESP8266 -arduino (it controls the gopro 8 with UDP protocol) and it’s connected to SERIAL4/5 (as 4) , it’s sending/reciving MavLink to Pixhawk. To control sonar/rngfinder, my ESP8266 is overriding the Channel 8, the channel 8 is connected (by wire) to Aux5. Aux5 is configured as rngfinder PWM, and the type of RNGFNDx_TYPE=5 offcourse. So overriding channel 8, gives me my own values to sonar/rngfinder. Sonar is in telemetry passthrough in 0x5004 packet, so in this way on ma lua scipts i have 10bit for use, to see what is the status of gopro. Range finder is configured as looking down to ground, becouse if not, the sonar is not getting any readings from rngfinder.
So crash nr.3 with atun.(with copter 4.x.x) First with 4.0.0, second 4.0.1 ,couple days later i noticed from facebook that there is a bug in autotune.
So i wait for 4.0.2, no probs, installed the new FW today and went for autotutune flights.
First flight i did only yaw&roll. that went ok and i did not noticed anything weird.
Change of battery and takeoff for autotune for Pitch axis.
My RC (herelink) gave notice that autotune complete, so i headed back to takeoff site.
As I approached, i noticed that craft wanted to go right even command was straight ahead, when i managed to get copter near landing site, it was really hard to control and end up crashing again, could be that landing would have been possible, but not for me today anyways…
Dont really know what happen, totally wrong pid´s, that´s for sure, i absolutely have no motivation to look at the logs today…maybe someone with more knowhow with logs be kind enough to take a look Great community
I will attach both flight log´s.
Here pids after autotune second flight-
Cube black / frame dji s900 / bat tattu 10000Mah / no gimbal etc.
AC 4.0.2 autotunes worked as expected and produced good results on the Quad X8, almost no other tuning required after following the new guide.
so, no one cares about this bug that is crashing my drones…is this community only for dev´s?
no comments no nothing…weird.
My guess is bad PIDs, you have a pretty horribly oscillation on pitch:
okay, but that was during autotune? before she flight nice.
Oh I see, sorry! No idea then - nothing jumps out at me. Have you been through the initial tuning guide on the wiki? https://ardupilot.org/copter/docs/tuning-process-instructions.html
i have gone thru that again and again. i just thought that someone is interested that there is same kind of behavior with atun than 4.0.0 - 4.0.1. im gonna do tuning manually again. dont trust this autotuning feature any more, tho its so much better than before, bu thats just me.
Thanks for your reply andy.
Were you flying with the autotuned PIDs? Or did you revert to defaults when the crash happened?
autotuned pids on air, dont remember. its all in the logs. Exactly same behaviour that i had with 4.0.1 autotune…even valueas that came from tune was approx same. useless feature at the moment. I dont recommend to do atun with larger copter at the moment.