Copter-3.6.1-rc1 is available for beta testing

Copter-3.6.1-rc1 will be available for beta testing within the next few hours. Anyone interested in giving it a try should be able to install it using MP or QGC using the beta option (for MP users, click the “beta firmwares” link). This beta release includes a number of important fixes on over 3.6.0:

  1. Garmin LidarLite V3HP support
  2. VFR HUD messages send relative altitude if DEV_OPTIONS = 2. Useful for older OSDs and GCSs
  3. 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)
  4. 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

Thanks in advance for those of you who can help us out with beta testing! If all goes well we will release it as the official version in about a week.


Hello thanks, i was reading trough the fixes and noticed TFmini and TF02 fixes, i have to report that SF20/C lightware does the same and reads 655 when going higher than readable distance. Would be nice for it to stay at latest good reading or zero.


1 Like


Thanks for the report. Any chance you’ve got a dataflash log showing the SF20/C reporting 655m? It would just save me some time in verifying the issue…

… but in any case, I think the drivers are quite similar so I suspect we can fix the SF20/C driver in much the same way as we did for the Benewake drivers.


pls review this thread:

did you switch tfmini specifically to pix mode and did you send in a specifically a “42 57 02 00 00 00 00 20” command? it is important. if done correctly, tfmini lidar will never report more than 12m distance.

Randy, it is worth to be adding to a wiki page about TFMini. this step is crucial - and if done correctly, nothing else is needed. i already stated that i have tfmini on 4 different models - on last 2 this command posted above and a checkbox on the ‘pix mode’ was the only setup i did, and it worked perfectly with arducopter after that.

Not sure the log is still there, have to check, in case i have it, will post it soon.

Hi Paul,

Re the Benewake lidar, Thanks for this. We could essentially do the same thing in the AP driver. We could make it so that if the sonar provides a negative altitude we report the RNGFND_MAX_CM + 1m (or something like that). This is better in someways than what I’ve done for 3.6.1 in that in 3.6.1 we essentially throw away the reading and this can lead to “lidar unhealthy” messages which is a bit annoying… because it’s not really unhealthy, it’s just that nothing is in view…

Hi Randy,

I think it makes perfect sense as essentially all what is needed is to switch tfmini into a pix mode and then issue that command i posted, or a version of that command to control that is produced by the lidar while out of the operational range. the way shown above to produce 12m reading while out of range actually worked very well so far.

1 Like

If AP firmware can automate this step without having to manually program the tfmini, so much the better for everyone.

1 Like

@Paul_Atkin1, @fnoop,

OK, I’ve got a change to the benewake driver so that when it gets an out-of-range value (i.e. 65534) it returns the value in the RNGFND_MAX_CM parameter + 100cm. In some ways it would be nice to just hard-code it to 12m but this raises the danger that the user could set the RNGFND_MAX_CM to > 1200 in which case the (bad) range would be accepted by the vehicle code and used as if it really was 12m.

I’ve placed a binary here based on Copter-3.7.0-dev in case you want to give it a try.

by the way, while testing this I’ve found that we’ve changed how we send the “Bad Lidar” message to the GCS. In Copter-3.5.7 “Bad Lidar” meant the lidar wasn’t sending any data (i…e it was broken) but in 3.6 we send “Bad Lidar” when it’s out of range. I need to discuss with the other devs about this change 'cuz I’m not sure I agree this is correct.

EDIT: I’ve updated the binary linked above to include a fix so that we report Bad Lidar only when the sensor is really not reporting data (i…e it’s still reported as “healthy” when it’s out of range)

1 Like

not sure, to be honest, will look at it tomorrow. on second thought lidar not sending any data is actually a proper code. as it will send out of range messages any time copter re positions away from the ground.

1 Like

Actually i think you are right, out of range doesn’t mean “bad health”, i think the best would be latest read altitude and “out of range” sign. Bad health can induce pilot in error, thinking lidar is falfunctioning even when not out of range.



1 Like

Flew with 3.6.2rc2. Performance is the same as 3.6.0, but liking the relative altitude thanks to DEV_OPTIONS=2 :wink: I’m still facing issues with RTL simply landing. See the flight below:

It hits RTL thanks to the battery failsafe, but no attempt is made to either reach the RTL height (20m) or to actually return to home. The copter simply descends. Very annoying. I’m having to switch off any FS action at the moment because I can’t rely on it. Log is here:

Still see the large drop in alt at takeoff, GND_EFFECT_COMP doesn’t appear to be helping at all:

it is very odd as my model does rtl just fine. it also has altitude issues so last attempt resulted in it reaching RTL location and them dropping down as a stone as something in the altitude computation probbaly glitched, but it definitely invokes RTL correctly.

i am not using smart RTL, a simple RTL only. which one did you have on the FS? i did not have time to play outside with rlt vs smartrtl yet.

also try setting desired altitude for RTL to 0, to make it go back at the current altitude and see what will happen.

Another issue I keep encountering is not detecting crashes. In this log the balance cable came loose and was banging against the props, I hit RTL and the copter flew into the ground at a shallow angle ending upside down. The props kept spinning until they broke and then kept spinning. I eventually had to gingerly pick it up flip it over and then it figured out it could disarm.

@rmackay9 I wonder if there is a logic error here? If it doesn’t detect a crash and is in a mode like RTL or PosHold its impossible to disarm because the motors are spinning wildly, even though the throttle is at zero. If I switch to stab then I can disarm ok. Log is here:

i had similar upside down crash behavior once, with props not stopping.
but i wonder if there is still something that can be done to reduce amount of your GPS glitch errors. i mostly cured all of mine - did you try to use shielded wires to connect to your gps and shield its mount plate? where does your gps sit and what brand is it?

It’s a
Video cables are all wrapped in copper as is the camera. It’s close to the VTX antenna and battery cable so interference there, but not a lot of options in terms of placement.

if you have any old iphone 4 charging cord - i did not try to cut new ones yet :slight_smile: - it has 3 wires inside and shield around it. you can use it for GPS serial and power wires feed. try to power off vtx completely and compare if amount of gps glitches will reduce. the module you use should be reliably at no less than 14 sats during flight if it does not suffer from interference. if it sits at 7-9 sats - it means front camera still is a problem. other way to improve gps signal reception is to use a piece of an antistatic plastic bag your Fc arrived in and put that piece right under the top carbon plate where GPS sits on. it is surprisingly effective.

frankly it is the most annoying part of ths model making process - to shield this stuff properly.
here is how my 7" chameleon front looks like now:
almost entire set of gps wires is hidden under copper tape. all camera wires are also wrapped and copper foil is grounded. in this setup it was picking up to 17 sats ok and stopped producing any gps glitches.

i looked at the log you posted - you have an immediate drop of gps sats from 9 to 6-7 and then a glitch.

i would try to put a small carbon plate with antistatic bag under it rigth above camera, give it a bit more space away from the battery, may be shift battery back more to have inch or so from gps to it back. and see if it wills top dropping sats so bad during maneuvers and ascents/descents.

if nothing helps then, well, you need a bigger puck than a compact matek -

1 Like