Copter-3.6.1 has been released and should appear in the ground stations as the default version within a few hours. We highly recommend users upgrade because it fixes a couple of important issues (see 3a and 4c).
WARNING: we have found a bug in the benewake TF02 and TFmini drivers which leads to a significant number of messages from the sensor being lost. A fix will be released in Copter-3.6.2 which will begin beta testing by the end of the week.
VFR HUD messages send relative altitude if DEV_OPTIONS = 2. Useful for older OSDs and GCSs
Bug fixes: a) Battery failsafe voltage parameter conversion fix
b) Safety switch startup fix (was occasionally not initialised properly)
c) Benewake TFmini and TF02 driver discards distances over 327m (avoids reporting 655m when can’t read distance)
d) Dataflash erase only availabled when disarmed (avoids crash if user attempted to erase logs while flying)
ChibiOS fixes and enhancements:
a) Pixracer LEDs colours fixed
b) Terrain support fixed on Pixracer, MindPx-v2, Radiolink mini-pix c) RC input processing fix to avoid memory corruption in some rare cases
d) FuriousFPV F-35 Lightning board support
e) SpeedyBee F4 board support
f) Bootloaders for OmnibusF4v6, mRoX2.1-777, Radiolink mini-pix
g) Revo-mini support for external barometer
h) Pins numbers made consistent across boards (setup of some features now more consistent across boards)
i) enable safety switch on Pixhawk family f7 boards
We have a few issues (see below) that we are looking into and hope to resolve in 3.6.2 but we still recommend 3.6.0 users upgrade to 3.6.1 in the interim.
“Bad Logging” message with some SD cards
“Bad Lidar Health” when a lidar goes out of range (just a display issue, doesn’t affect flight)
Will test asap.
Looking forward to “Bad lidar health” fix, i get it all the time with my SF20/C whenever i fly over 40 meters (lidar should be ok up to 100m still trying to understand where is the problem).
I believe there is a behavioral change in 3.6.1, as compared to 3.6.0 and earlier, in how the MotorTest from Mission Planner works. Now, when I hit a motor button the motor immediately starts to turn, while before there was a sort of a delay with some sort of warning beeps.
I went through the PRs, but from the titles and comments I can’t see that change. So, it’s not clear to me if that was intentional or not, if it is noted or known or not, etc. I hence thought I should mention it.
It’s not a big point, but I like the behavior with a delay and warning beep better. The new behavior at least came as a surprise, I would have appreciated it being mentioned in the RNs.
Cheers, Olli
PS: More details:
To be precise, what I did today is to upgrade my betacopter fork which was based on AC3.6.0 to be based on AC3.6.1 (doing it as I always do it), and yesterday it behaved the old way and now it’s different. Note: my fork doesn’t touch any of these code parts; there was no merge conflict. So I believe the observation is representative for AC3.6.1.
I yesterday realized that the old-way’s “delay beeps” were not generated via the AP_ToneAlarm class, so I suspect that this was done by some lower-level stuff, and that it’s gone now because of some changes in the “lower level stuff” (IO?).
olliw42,
i never observed any “warning beeps” before motor test. Neither in AC 3.4, nor 3.5. nor 3.6.0.
Motors started always immediately after clicking the button “Test Motor X”
So no change in behavior for me in AC 3.6.1
thx for the info
I have a totally different experience though
(and I had my “old” experience just refreshed yesterday)(and I generally use that function quite often)
not sure if it depends on which FC, the tests yesterday/today were with v2 (nuttx of course)
as said in the 2nd PS, the “old” beeps and delay appear to have come from somewhere low level
EDIT: Is it conceivable that I appeared to always get two sounds when I trigger the MotorTest? That is something like the regular motor test beep plus some, I don’t know what, other beep (prearm, ekf, vib, blabla), and that I now happen to not get the additional beep?
Anyway, if it appears to be only me, then I guess all is good and it’s just me :).
After update from 3.6.0 to 3.6.1 noting work…
after many attempts I found the problem, with version 3.6.1 the display SSD1306 blocks the telemetry on the usb port making it impossible to communicate with the FC (in my case a mini pix).
Roll back to 3.6.0 and all working fine
i’m still having issues with Dshot boot up.
It seems that ESCS are booting up sooner then Pixhawk 2.1 and it cant configure the esc to Dshot 150 state.
And MP doesn’t even show anything about it.
I can do takeoff and half of the motor won’t even start…
How to fix it if i see that one of the esc isn’t boot correctly i reboot software way and everything is everytime alright.
Why isn’t there any feedback from the esc that some of them dosen’t work.
We discussed this with @tridge on the weekly dev call and he says the issue is that the SERVO_BLH_MASK is set incorrectly. On the pixhawk family of flight controllers the DShot ESCs need to be connected to the auxiliary outputs (i.e AUX1 ~ AUX4) but if SERVO_BLH_MASK is 15 this means use the MAINOUT1 ~ 4 (which don’t support DShot actually).
Can’t update correctly with mission planner , so i did it with QGc , but all my parameters were erased.i was not able to connect 3.6.0 to MP under windows , but this one connect!so i guess i have to recalibrate and adjust everything:disappointed_relieved:
I’m really sorry to hear that. Do you have any more details about the series of events that led to the loss of your parameters? Some questions… not trying to give you the 3rd degree of course, just trying to find ways that we could try and reproduce it.
what flight controller was being used?
what version was on the board before?
what version were you trying to update to? 3.6.0? 3.6.1? was it ChibiOS or NuttX?
was any error message displayed when the upload failed?
is it possible that when using QGC another flight stack’s firmware or another vehicle type was accidentally uploaded?
have you had any problems with the SD card or logging before the upload?
Hi, yes i uploaded the wrong firmware… i was using 3.6.0 rc11 with ChibiOS on PX4v2, now with the correct firmware, i am looking for the Vbatt multiplier parameter, and in the failsafe , i can’t adjust the battery level for triggering, they are grayed.Another thing , if i try to upload an older firmware like 3.5.7, my card is not recognized in the process.
No problem with the SD card except sometime “no heart beat” when power on , but not very often.
Thank you for your help.
OK, if you uploaded the wrong firmware (i.e. a different ArduPilot vehicle or non-ardupilot code) then I’m afraid it is expected behaviour that the parameters are wiped.
Re not being able to update the battery level, could you try updating the MP? Go to it’s Help screen, then press the “Check for Updates” button.
i am using 1.3.59 and it says no updates , where is the voltage multiplier parameter for the battery voltage input?BTW , why AC3.5.7 is the latest firmware before 3.6.1, not 3.6.0?
After many testing i found the parameter on QGControler,hopefully i can make a flight test tomorrow.It appears that in MP , i can’t upgrade and rollback anymore, i have to download the firmware separately and use “upload custom firmware”
![esc%20missing|690x321]