Copter-3.6.7-rc1 has been released for beta testing and can be installed using the Ground Stations’ “beta firmware” link. This is a relatively minor update from 3.6.6 with just four fixes that are in the ReleaseNotes and also listed below.
Changes from 3.6.6
Bug fixes and minor enhancements
a) Matek405-Wing compass fix (thread initialisation fix)
b) Flips during landing reduced by reducing I-term build-up
c) Land mission command slows down less aggressively
d) Lightware LW20 lidar more reliably switches to serial mode
All feedback is greatly appreciated. In particular it would be great to hear back from users of the Matek405-Wing board and users of the Lightware LW20 ildar (especially those using the serial interface).
Hi!
Please tell me when you plan to fix the sound during the compass calibration for “Matek F405”? Now it is impossible to calibrate the compass in the field, without a computer.
It’s on the to-do list but we haven’t gotten to it yet. I’ll try and bump up the priority on that.
By the way, it shouldn’t be necessary to re-do the compass calibration unless some equipment on the vehicle has been moved around which could affect the magnetic field. ArduPilot includes a small database that holds the declination (the difference between true north and magnetic north) values for anywhere on Earth and the EKF detects the “inclination” soon after startup. So there’s generally no need to re-do the compass calibration.
We have another problem with the sound. As I noticed on the original " PixHawk "the sound warning is played after the appearance of 3D Fix. I don’t have this sound on Matek F405 CTR either.
Using 3.6.6 NutX results in a functioning LIDAR, while 3.6.6 ChibiOs produces ‘bad lidar health’ messages, along with random readings distance readings. When I install 3.6.7-rc1 using ChibiOs, the behavior of the LIDAR appears to be the same as 3.6.6 NutX, so I would say that your driver fix worked.
I haven’t flown this release yet, and I will probably hold off seeing as this is a customer’s vehicle and I don’t want to risk such a large machine (25+kg) (although I am sure it will be fine).
I just wanted to update you on the driver behavior in 3.6.7. Also, I am powering the lidar from a 5V BEC (mauch power cube). If I power the LIDAR and pixhawk 2 at the same time (by plugging in the battery) I get bad lidar health warnings; but if I power the pixhawk 2 first, and then power the lidar afterwords everything seems fine. I know this is probably a hardware problem, but I wanted to include it for completeness.
@BRiskas, great, thanks for the feedback. Re the startup order … it sounds a bit like the lidar isn’t waiting long enough when making the I2C vs serial protocol decision. I’ll pass this onto Lightware and we should probably create an issue to capture this as well (i’ll do that). Txs again!
I was wondering if anyone else had given this beta version (3.6.7-rc1) a test fly? I’ve flown it and it seems OK but I’m keen to hear back from others…
If there are no issues I may release this as early as later today or tomorrow…
I’m not sure if MP will notice the difference between a beta and stable because they have the same number. It is possible that it can see the difference based on the type but I don’t know if it does that so I’ve asked MichaelOborne.
Randy- Thanks for the information. A few more details for you to mull about: The pixhawk 2.1 and LIDAR are powered by a mauch power cube 4 (v3). The pixhawk has independent 5v sources for primary and secondary power, while the LW20 and rfd900 radio share a 5V power supply.
When I connect the batteries, the powercube has a 2 second delay, at which point it powers the pixhawk, rfd900 radio, and lw20 lidar simultaneously. If I power the UAV by connecting the battery, I get no signals from the lidar (although the rfd900 works perfectly). If I power the pixhawk first via USB, then connect the batteries to power the pixhawk, rfd900, and LW20, the lidar connects and works well (proper distance readings in the ‘sonarrange’ status tab).
My current workaround is a small delay circuit inline with the LW20, which waits for 2 seconds after the BEC turns on before powering the LW20. So far this fix seems to work, although it does require an extra small PCB. If this could be fixed in software that would be great, as I could ditch the extra hardware workaround.
There is also an operational workaround in that I can power the pixhawk via USB (laptop or similar) and then power the rest of the peripherals with the battery once the pixhawk is initialized. This seems to work well, but it is a pain in the field, and not always practical. BTW this behavior was observed on 3.6.6 NutX and 3.6.7-rc1 ChibiOs. 3.6.6 ChibiOs did not seem to cooperate for me with this setup.
Thanks for the feedback! That is indeed a nice looking copter, it looks like a tealdrone which I didn’t realise until a few days ago has a pixhawk compatible flight controller in it (along with the NVidia TX1). I’m jealous whatever it is! In any case, very nice!
Thanks Randy,
It is the first prototype of a project that I am developing, at the moment I am making some modifications to the frame so that the appearance is even better.
Definitely getting off topic but it looks like it has a little gimbal on the front there as well. very interesting… if it’s going to be hackable (i.e. I can load my own flight code on there) I’d be interested in buying one… anyway, no pressure … nice!