Copter-3.6.0-rc6 available for beta testing

Roland,

OK, we have a fix for the channel 12 auxiliary switch issue. It’s actually already been fixed in master so it will go out with -rc7. Thanks for your persistence!

Thanks too Randy,
will continue the tests and hopefully the great dev-team will also fix the Dshot Kiss-ESC behaviour.

1 Like

Quick test flight ChibiOS on a Classic Pixhawk and all was well flew smooth legs retracted GPS was nice.

1 Like

hi,
i am not sure if it should be a separate topic or may be considered a fix request.
it is about a whole situation with support for frsky pass-through telemetry.
on all betaflight models all what needs to be done is to connect Tx from some serial port directly to r-XSR smartport. that`s it. then, on some scenarios there is a signal inversion parameter that can be adjusted - on or off. there is no need for _any_hardware nonsense to be set on top of it. 1 wire, 1 port, one way stream that starts on its own.
here, for arducopter, to support same exact telemetry feed, from same controller into same receiver people have to do crazy contraptions like this, with no guaranteed result:
https://discuss.ardupilot.org/t/some-soldering-required/27613/12

and it just escapes me, WHY? is it possible to add inversion and other required config options to the ardupilot to stop all this soldering nonsense with diodes and resistors to make same feature work in a same way as it works on betaflight, just pushing out frsky passthrough telemetry stream from a single soldered wire to a particular Tx? Doesn`t it just make sense - if it works on betaflight, on the same hardware, what is the issue to make it work same way here?

@Paul_Atkin1 it’s the wrong thread. FMUv2 units (the regular Pixhawk and derivatives) were designed and built before S-Port ever saw the light, and have the “failsafe” STM32F1 for direct-output of the RC inputs, blocking some features of the “main” STM32F4. You’ll find the straight S-Port pin on most recent designs, like the FMUv4 (Pixracer) which did away with the failsafe processor.

Chibios 3.6 is now getting to a lot of FCs that ran Betaflight. It is no longer pixhawk only thing, but, if there is a thread for compatibility issues, i can post there. I think 3.6 is supposed to work on any hardware.

Back to what i wrote - issue is that we need either add an option or new code to augment code 10 to produce inverted stream of s.port output

i think there is a major issue with DSHOT protocols in 3.6 release - i just tried to set DSHOT300 on this test kakute build - and, who knows what it is wrong with it, but, from the disarmed state it was jerking both left motors with small pulses causing minor rotation and then - out of sudden, it gave by the sound a half to 3/4 of full throttle to right motors, good thing i had no props on. there were no issues at all with this same model with multishot 125 selected.

i remember with used with pixracer i had similar motor jerks - but on all 4 motors, but on pixracer it did not give me full throttle while disarmed. that is when i switched away from it to multishot 125.

1 Like

Paul,

Thanks for the report on D-shot. It looks like a few users are having issues so I’ll ask @tridge if he can replicate…

Hello all,

I’ve just loaded ChibiOS 3.6.0-rc6-heli onto my Pixracer board fitted to my Trex 450 pro after I had a successful day testing on NuttX 3.5.7-heli. Think i enjoy the setup more than anything else and exploring the parameters.

I have noticed this compass issue on the Pixracer board. Can i please confirm that disabling the internal compasses will work as a temporary fix until the issue is found? I thought i read somewhere that downloading logs was fixed in ChibiOS, i did a test download after first upgrading and the HUD showed bad AHRS. After a reboot it did not appear to do this again.

Anything else i should be weary of?

TIA

1 Like

I had the internal compass’s disabled already before loading 3.6-rc6 Chibios and the external one would not function after loading it so I would say no, we need to wait for rc7. I reverted back to 3.5.7 in the short term on that particular quad.

@dkemxr What do you mean “Would not function”. Mine has calibrated fine on the bench and appears to show true heading in mission planner. Is there another metric for testing that I should be using?

Ah, you may be OK then. Mine would not calibrate and was non-responsive in the HUD along with error messages. I can see why in the device ID’s because Compass one, which should be the external one, is not identified correctly. The compass chip is but the bus type/address is not. In the attached the data for the 1st compass shown (460042) is wrong and what rc6 reports. The 2nd one shown is correct and what current stable reports and which functions [properly.

Comp%20device%20ID

when you get this problem, what value do you have for MOT_PWM_TYPE?
One likely cause is slight difference in the clock between the ESC and the flight controller. So for example, if you setup the ESC for 1000 to 2000 PWM, and you setup ArduPilot for the same range (using MOT_PWM_MIN and MOT_PWM_MAX) then you may find you need to lower MOT_PWM_MIN to 990 or so.
This is not relevent if using DShot, which is why I asked about the MOT_PWM_TYPE.
Also note that if you are using a flight board with an IOMCU (eg. Pixhawk or Cube) then setting MOT_PWM_TYPE to DShot does not work on the main outputs (the first 8 channels).
Cheers, Tridge

i had motors turn with mot_pwm_min and max set to radio values, and also when those were set to 0, on both dshot 300 and dshot 600. with multishot125 all flies well and behaves fine. it was with pixracer, on kakute 7 motors 3 and 4 are compromised by hardware - but 1 and 2 were also jerking/ spinning at disarm.

When using MOT_PWM_type: 2 (oneshot125) this issue does not occur (i have all my endpoints set up with enough room). Thats what i currently fly on my BLHeli-S multirotors.
Only with type 4 (Dshot150, I did not try a higher one) In combination with a BLHeli-S esc.
Changing nothing but the esc to a BLHeli-32 esc solved all my D-shot issues.

@tridge if you’re wondering what it looks like, I made a Youtube video of the behavior with a BLheli-S and a -32 esc. Without changing a thing (except the giving the other esc a motor and power).
All of this should be disarmed.
I’m on 3.6.0-RC6

Hi,
just a quick sanity check - it is a most recent MP interface, with rc6 code.
are we supposed to have all sections ‘throttle accel’, thr rate, alt hold, velocity - all grayed out? are all those parameters deprecated?

Names changed, MP not following yet, set them in full parameter list or tree.

Paul,

txs for the report.

I’ve created a to-do item for the MP to correct the parameter names so I hope/expect that @meee1 or someone else will get to it in the near-ish future.

Randy, on the same topic - in the MP, compass/motor calibration feature is broken again. not sure what was altered - it did work before for rc5 and rc6, but, no more. when you get into that window, it prints:

Initializing APM
Starting calibration
Current
Failed

i know it did work before as i calibrated model with pixracer on it, and now on same parameters it refuses.

1 Like