We’ve just release Copter-3.6.2-rc2 for beta testing and it should be available within a couple of hours from Mission Planner and QGC using the Beta Firmware selection of each app.
This release has just three changes that are listed in the Release Notes and also copied below:
Bug fixes:
a) Benewake TFmini and TF02 driver checksum fix (was missing many sensor readings)
b) Range finders report healthy to GCS when out-of-range
c) RPM sensor reliability fix by initialising analog input pin
Thanks very much to those users who took the extra time to report issues here on the forums, providing dataflash log and helping us work through these niggling issues!
P.S. if you’re wondering, “what happened to 3.6.2-rc1?” - we decided to include the last fix for the RPM sensor just as the release was going out.
Just gave 3.6.2-rc2 a quick test on a mRo Pixracer (1year old) with ChibiOS. It fails to boot as soon as a SD card is inserted. The startup seems to freeze after a couple of yellow blinks, but before red/blue Gyro calibration signals. No suitable text output on USB or Dronecode probe. Without card, it boots up fine with all versions.
The SD card has been freshly formatted with Windows and Linux (FAT). I tried two different cards, a 2GB and the 8GB originally included in mRO PixRacer package.
After switching to latest master, the problem is gone. Unfortunately, master is also not suitable to get off the ground at the moment (bus this is worth a separate thread). After switching back to branch “Copter-3.6” and doing a clean rebuild, the SD card problem is back.
Here is a short test log:
e4a48282037aec5173c71770fa331dfe2b709dff (local build, 3.6.0-rc12?) : ok
2eedcf5678e866c6296379a659d80fb6e2adbb92 (local build, 3.6.0) : ok (wrong colors)
f37cf57040a77a847043a24bb12719b0b57a8a33 (local build, 3.6.2-rc2): fail
296132b876efca7672b9d5fa44641502d5c3cf88 (local build 3.6.1): fail
2eedcf5678e866c6296379a659d80fb6e2adbb92 (local build, 3.6.0) : ok (wrong colors)
296132b876efca7672b9d5fa44641502d5c3cf88 (local build 3.6.1): fail
After these tests, I think that the breaking change has happened between 3.6.0 and 3.6.1
I just tested the Copter-3.6 branch with a Pixracer, with a microSD card. It works fine, and logging works.
I think there is something more subtle going on. I’ve got a microSD breakout board arriving soon that I will use to try to get to the bottom of failed microSD operations.
Cheers, Tridge
Did you format the card beforehand? The problem seems to be related to the missing TERRAIN folder on the card. When reverting that commit, even 3.6.2-rc2 works fine again.
i saw in earlier builds, a long quite ago - there was something causing issues if a TERRAIN function is disabled in the hwdef and folder is not on the card - it would fail, but if you make that folder manually - it would work fine. i then just activated TERRAIN feature in the hwdef and it all went away and i never saw error again. perhaps if you format the card and hwdef has no terrain feature - it may be the issue.
Does anyone know if the OSD on omnibus boards is working in this release?
I recently realized I’ve been running master for a while… The last time I tried 3.6, the OSD was not working for omnibus boards (but was working on the kakute and others…)
thanks
I have the same problem on F4BY, it looks even worse. It also fails to boot as soon as a SD card is inserted. After switching back to Copter-3.60 the problem is gone. when switching to 3.61 and 3.62 the problem comes again. The startup Seemingly to before Baro carlibration. I checked SD card LOGS and TERRAIN folder on it. 3.61 and 3.62 could be startup Successfully until removed SD card .
Here is messages on MP
SD card is inserted
Check BRD_TYPE: Baro: unable to initialise driver
Check BRD_TYPE: Baro: unable to initialise driver
Initialising APM
Check BRD_TYPE: Baro: unable to initialise driver
Initialising APM
Check BRD_TYPE: Baro: unable to initialise driver
Frame: QUAD
F4BY 0050004B 33375108 32343337
ChibiOS: ff603d11
ArduCopter V3.6.2-rc2 (f37cf570)
I don’t know for sure if the OSD is working on Omnibus but we did update all the hardware definition files with this release so if it was a pin mapping issue or something like that it could be resolved.