ardupilot icon indicating copy to clipboard operation
ardupilot copied to clipboard

Support reversible mask in iomcu

Open andyp1per opened this issue 1 year ago • 4 comments

We were sending the command but not coping when actually sending the dshot packet

andyp1per avatar Aug 13 '24 16:08 andyp1per

I think we also need the armed state? so we can send dshot value 0 when disarmed. Not doing that for 3D ESCs is dangerous We have the flag P_SETUP_ARMING_FMU_ARMED left over from earlier versions of IOMCU but we don't seem to use it, I think we need to check hal.util->get_soft_armed() and send that flag over to the IOMCU, otherwise reversible ESCs are too dangerous

Note we do this: image so on FMU we do send 0 always when not armed, on IOMCU we don't as far as I can see

Good catch! Now I understand why @bugobliterator commented this out on IOMCU. It's a little more subtle as the armed state needs to be propagated as well, but certainly doable.

andyp1per avatar Aug 14 '24 13:08 andyp1per

I verified with a Saleae that:

  • disarmed + safety - no output
  • disarmed + safety disabled - zeros output
  • armed - zero throttle output

andyp1per avatar Aug 14 '24 16:08 andyp1per

testing on Pixhawk6x-bdshot with Sub, with 10% throttle: image OUT1 is IOMCU, OUT9 is FMU note that the signal is idle-high on IOMCU, and AM32 doesn't recognise it: image

tridge avatar Aug 18 '24 23:08 tridge

I have now tested this successfully on a CubeOrangePlus

andyp1per avatar Aug 20 '24 17:08 andyp1per

@andyp1per I've been testing this with both BLHeli32 and AM32 ESCs on a Pixhawk6X-bdshot board, testing with rover It all works on FMU, but on IOMCU we never send the command code to set the ESC to 3D mode.

tridge avatar Aug 29 '24 03:08 tridge

I discussed with @andyp1per and it only affects rover and sub and he thinks it's best that we wait for 4.6 which will start beta testing soon anyway

rmackay9 avatar Sep 25 '24 10:09 rmackay9

I've got a result and a fail - the SERVO_BLH_RVMASK now works BUT the bitmask seems to be mapped randomly to servo channels or motor positions. Using a Quad X8 I couldnt tell what bit would affect which motor without first testing all individually. When I last used SERVO_BLH_RVMASK it was on a FC without IOMCU and I seem to remember the "bitmask channels" aligned to the Servo channels regardless of which motor function was assigned to which servo channel.

RCOut: DS300:1-8 PWM:9-13 IOMCU: 420 1001 411FC231 CubeOrange 00330033 3131510E 31363832 ChibiOS: 88b84600 ArduCopter V4.6.0-beta1 (8d4976cd)

I am using the standard Octaquad (X8) motor positions and wiring, to the Main Out servo connections as follows:

Letter Servo Dir needs reversing A 1 CCW B 6 CW reverse C 4 CW reverse D 7 CCW reverse E 3 CCW F 8 CW G 2 CW H 5 CCW

Tests of each bitmask value produced: bitmask "channel" (decimal value) => letter/servo ch 1 (1) => D 7 2 (2) => C 4 3 (4) => E 3 4 (8) => F 8 5 (16) => G 2 6 (32) => H 5 7 (64) => A 1 8 (128) => B 6 which appears to have no relationship, such as bit 0 mapping to Servo 1 would be nice and logical.

I had to use this bitmap to reverse motors B/6 , C/4 , D/7, => 1,2,8 bitmask for SERVO_BLH_RVMASK,131

I would have expected 4,6,7 = SERVO_BLH_RVMASK,104 decimal

xfacta avatar Dec 10 '24 06:12 xfacta