Copter-3.6.5-rc1 is available for beta testing and can be downloaded from the various ground stations using the “Beta Firmwares” option. There are some important fixes over 3.6.4 which are in the ReleaseNotes and also copied below:
Bug fixes and minor enhancements
a) SD Card reliability improvement (BRD_SD_SLOWDOWN param) and allow re-inserting card after boot (ChibiOS only)
b) Mode and Auxiliary switch range check to protect during FrSky SBUS failsafe recovery (issue, fix)
c) Follow mode reports target distance and heading to ground station
d) Pixhawk4-mini safety switch and LED fix
e) Bebop2 build fix
RC protocol decoding for SRXL, SUMD and ST24 extended to all boards including pixracer and ChibiOS-only boards
DrotekP3 Pro support
Cube Purple support
Any testing and feedback people can provide is greatly appreciated! In particular we are interested to hear:
for users who were having SD card problems, does this version work better?
Just tested this yesterday on a pixhawk AR7700 Spektrum transmitters. Working well. Moving from PPM to SRXL recommend calibrating radio and escs as a precaution.
In this version began to fail the receiver. I use SPM4649 and Spektrum DX8. The eighth channel I have assigned to Arm / Disarm and now I see how periodically its value becomes equal to “0”. The log is attached…
Just a comment that i hope it is taken as constructive.
I keep seeing patches over patches to fix different problems on different boards. Ardupilot wants to support all hardware possible (boards) and segmentation grows together with minor problems popping up everywhere.
In my opinion would be much better to have strong support on 3-4 different boards (reference design to wich manufacturers stick) and concentrate more on stuff like Ollie’s UAVCAN that would really bring the system to an higher level. It is a shame that devs time is wasted on minor problems due to too much hardware segmentation and not used on the system itself.
I really think we are going badly in the wrong direction
Corrado
p.s. this is a comment made as polite as possible on what i think about where development is going, i repeat it is just my opinion. Please all “everything is perfect” people just ignore my post.
I support @anon67614380’s views that there could be 3 to 4 different boards that would be in my opinion ranging lowcost/lowend to highcost/highend boards. In my opinion those “main” boards doesn’t really differ a lot from each other. Actually for me it seems that currently there is no “high end” main boards available. The cube is still designed to a price point and has some flaws due that. I would like to see an autopilot hardware with high end IMU’s (like ADIS16475), those alone do cost more than “Cube”, but sometimes the cost is not a issue when best possible reliability and performance is needed.
UAVCAN should be pushed forward and reference designs for those UAVCAN sensor hardware. When UAVCAN becomes popular, then even those lowcost mainboards can have the IO/sensors needs satisfied with UAVCAN bus.
No, I’m afraid not. We talked about it on the previous dev call and it’s apparently not difficult to make the UAVCAN compasses appear first like other external compasses but it hasn’t been done yet. Until this is done, it’s probably best to disable some of the other internal compasses using the COMPASS_TYPEMASK parameter.
@xfacta, the Buzzer PR will need to get into master first I think. Re getting it into a point release - it’s possible although normally we try to limit the point releases the bug fixes although we sometimes include low risk stand-alone enhancements.