Servers by jDrones

Copter-3.6.5-rc1 available for beta testing!

beta-testing
beta-release

(rmackay9) #1

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:

  1. 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
  2. RC protocol decoding for SRXL, SUMD and ST24 extended to all boards including pixracer and ChibiOS-only boards
  3. DrotekP3 Pro support
  4. 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?
  • FrSKY SBUS users notice no difference?

Thanks!


(Hari .P) #2

Thank you…

I think the SD card problem solved.[checked by plugging & unplugging 10 times]


(brandon macdougall) #3

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.


(Roman) #4

Hi!

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…

00000022.BIN (440 KB)

This bug with the eighth channel was in an earlier version of 3.7dev, because of this, I stopped to use it.

And another question for this version: how to see the RSSI that transmits spm4649t?


(anon67614380) #5

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 :slight_smile:

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.


(LJu) #6

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.


(Ramon Jose Moreno) #8

Hi all

I tested an SD memory to not work with firmware chibios and now if it works

making reference to the problem in this post:

Thank you very much to all the software development team

regards to all


(rmackay9) #9

@nomar, Great thanks for the feedback. So to be clear, the SD card is working now with 3.6.5-rc1?


(tridge) #10

Thanks for reporting this!
I believe I have found the bug, although it doesn’t happen for me. Can you please test this firmware:
http://uav.tridgell.net/Andreyl/copter-3.6.5rc1-dsm-fix.apj
That is 3.6.5rc1 with this PR applied:


(tridge) #11

how does it give RSSI? It is an analog pin? Or a PWM on a channel?


(Roman) #12

This firmware can be flashed to the controller “Matek F405-ctr”?

RSSI information is transmitted within the Protocol:
Remote Receiver Interfacing.pdf (569.2 KB)


(tridge) #13

yes, I built it for MatekF405


(Roman) #14

I confirm, in this firmware there is no problem with the eighth channel


(Ramon Jose Moreno) #15

Hello Randy, I’ve tried a sd memory that did not work in version 3.6.4 chibios and now it works the version 3.6.5-rc1

I feel for my English so bad.

regards


(rmackay9) #16

@nomar, Great! thanks for the confirmation.


(anon67614380) #17

Is there any patch in 3.6.5-rc1 to solve the UAVCAN 2nd external compass not seen by system?

Corrado

p.s. Understand is not as bad as the 8ch on Matek F405-ctr but still would be nice to have a solution.


(rmackay9) #18

Corrado,

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.


(anon67614380) #19

Ok, will wait. For some reason disabling internal with typemask doesn’t work. Keeps not seeing it.


(Shawn) #20

Any chance of getting the extra NTF Buzzer options https://github.com/ArduPilot/ardupilot/pull/10067
into a beta or a RC soon?


(rmackay9) #21

@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.