Pixhack v5: Main PWM Glitch

[tops4u]

Describe the bug
This the same Problem as #8601 for mRo X2.1. When rebooting the Controller i.e. on the Shell in QGC just before coming online the Rotors of my Hexa spin about ¼-½ turn.

To Reproduce
Steps to reproduce the behavior:

1. Boot
2. Open Shell in QGC
3. Issue Reboot Command

Expected behavior
Rotors do not spin without prior Arming.

Log Files and Screenshots
N/A

Drone (please complete the following information):

• Hexa X
• Normal PWM ESC

[tops4u]

@davids5 is this the same Problem we have/had on mRo X2.1? I forgot that the Board is running Master about 1-2 Weeks old.

[davids5]

@tops4u Would you please add a picture of the wiring

[tops4u]

Hi @davids5,

sure thing. The Setup is under construction, this is why it does not look too nice.

Also I attach a video where you can see the two front Props spinning after Reboot.

IMG_2903.m4v.zip

[tops4u]

It is also random which Motors spin. Sometimes none, sometimes all of them or just two, as above.

[davids5]

@tops4u - I know it is hard to tell, but can you tell if the spin is in the reboot, bootloader or PX4?

With USB:reset----->bootloader 5 sec ----------->PX4 App

[tops4u]

I could check serial Console if this is of any Help? Is the Output there only from the FMU?

[davids5]

I was thinking the leds would help but I can not tell from the video.
reboot ---------V
PX4 breathing -X-- bootloader flutter ---- PX4 Solid --- PX4 breathing

Yes just FMU is on console.

[tops4u]

Hi @davids5 I loaded the File into Audacity and the Moment I hit Enter can be heard and it is at 2.469 secs in the Video, the moment the Props start spinning is at 7.649.
I don't know how long the Reboot Routine takes but also if I look at the High Res Video, I would say that they Spin after the Police Light stops which is in the same moment the RDB LED Flashes up green the first time, then the Props spin.

[tops4u]

@davids5 I have made one more. The following Video I recorded the Console and you can hear the Props start spinning when the Mixer Command for Hexa appears on the console log.

Do you need me to do any other logging or stuff?

Reboot-Glitch Console.mov.zip

[davids5]

@tops4u - Thank you for doing the heavy lifting! @dagar, @LorenzMeier This sounds like an issue with the PX4IO during loading and not the short pulse issues we had on V4. Code inspection would be the place to start - whos up for it?

[LorenzMeier]

@tops4u Could you please share the output of:

px4io status and pwm info? Thanks!

[tops4u]

Here we go (note: RC TX was off). I just hope I didn't mess up something like when there was an old extras.txt on the SD Card confusing SBUS Input.... Anything I should check for? Would you want the Param Config?

PX4IO STATUS:

px4io status

WARN  [px4io] loaded
protocol 4 hardware 2 bootloader 3 buffer 64B crc 0xc211fdd3
8 controls 8 actuators 18 R/C inputs 2 analog inputs 0 relays
1400 bytes free
status 0x3741 OUTPUTS_ARMED SAFETY_OFF RC_FAIL FMU_OK MIXER_OK ARM_SYNC INIT_OK
alarms 0x0030 FMU_LOST RC_LOST
vservo 9730 mV vservo scale 10000
vrssi 3290
actuators 0 0 0 0 0 0 0 0
servos 900 900 900 900 900 900 0 0
reversed outputs: [________] trims: r:   0.0000 p:   0.0000 y:   0.0000
0 raw R/C inputs
R/C flags: 0x0000
mapped R/C inputs 0x0000
ADC inputs 4068 4082
features 0x0008 RSSI_ADC
arming 0x0431 FMU_DISARMED IO_ARM_OK INAIR_RESTART_OK ALWAYS_PWM_ENABLE OVERRIDE_IMMEDIATE
rates 0x00ff default 50 alt 400 sbus 72
debuglevel 0
controls 0: -5761 1251 -463 500 0 0 0 -10000
controls 1: 0 0 0 0 0 0 0 0
controls 2: 0 0 0 0 0 0 0 0
controls 3: 0 0 0 0 0 0 0 0
input 0 min 1094 center 1512 max 1934 deadzone 10 assigned 0 options 0x0001 ENABLED
input 1 min 1094 center 1513 max 1934 deadzone 10 assigned 1 options 0x0003 ENABLED REVERSED
input 2 min 1094 center 1094 max 1934 deadzone 10 assigned 3 options 0x0001 ENABLED
input 3 min 1094 center 1512 max 1934 deadzone 10 assigned 2 options 0x0001 ENABLED
input 4 min 1017 center 1489 max 1962 deadzone 10 assigned 255 options 0x0000
input 5 min 1000 center 1420 max 1840 deadzone 10 assigned 255 options 0x0000
input 6 min 927 center 1514 max 2102 deadzone 10 assigned 5 options 0x0001 ENABLED
input 7 min 1094 center 1514 max 1934 deadzone 10 assigned 255 options 0x0000
input 8 min 1094 center 1514 max 1934 deadzone 0 assigned 255 options 0x0000
input 9 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 10 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 11 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 12 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 13 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 14 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 15 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 16 min 998 center 1498 max 1998 deadzone 0 assigned 255 options 0x0000
input 17 min 998 center 1498 max 1998 deadzone 0 assigned 255 options 0x0000
failsafe 900 900 900 900 900 900 0 0
disarmed values 900 900 900 900 900 900 900 900

and PWM INFO:

device: /dev/pwm_output0
channel 1: 900 us (alternative rate: 400 Hz failsafe: 900, disarmed: 900 us, min: 1040 us, max: 1950 us, trim:  0.00)
channel 2: 900 us (alternative rate: 400 Hz failsafe: 900, disarmed: 900 us, min: 1040 us, max: 1950 us, trim:  0.00)
channel 3: 900 us (alternative rate: 400 Hz failsafe: 900, disarmed: 900 us, min: 1040 us, max: 1950 us, trim:  0.00)
channel 4: 900 us (alternative rate: 400 Hz failsafe: 900, disarmed: 900 us, min: 1040 us, max: 1950 us, trim:  0.00)
channel 5: 900 us (alternative rate: 400 Hz failsafe: 900, disarmed: 900 us, min: 1040 us, max: 1950 us, trim:  0.00)
channel 6: 900 us (alternative rate: 400 Hz failsafe: 900, disarmed: 900 us, min: 1040 us, max: 1950 us, trim:  0.00)
channel 7: 0 us (alternative rate: 400 Hz failsafe: 0, disarmed: 900 us, min: 1040 us, max: 1950 us, trim:  0.00)
channel 8: 0 us (alternative rate: 400 Hz failsafe: 0, disarmed: 900 us, min: 1040 us, max: 1950 us, trim:  0.00)
channel group 0: channels 1 2
channel group 1: channels 5 6 7 8
channel group 2: channels 3 4

[LorenzMeier]

And the saved parameters please? Just so I can configure the same airframe.

[tops4u]

And here are the Parameters.

HexaV5.params.zip

[LorenzMeier]

@bkueng Would be good to look into and resolve but sounds like its more a nuisance for Andreas than a safety issue right now. But I don't want to have this slip for too long.

[tops4u]

@LorenzMeier that may be true, but it scared me quiet a lot when it happend the first time on my Desk when there are 2.7kW Peak Power with Props mounted starting to Spin unexpected just 20cm in front of me...

Now I know that it is not a big deal, but still inconvenient at times when there is not a lot of Space on my Workbench, the Props may still hit something or somebody.

For Safety Reasons I should probably unmount my Props more often 😬

[bkueng]

I was looking into that, and here are my findings so far:

• It's quite easy to reproduce (as described by @tops4u )
• I reproduced this with a Pixhawk 4 as well
• The result is always the same: there's one longer pulse around 1600us.
• I tracked it down to the pwm rate ... call that happens after the reboot in the startup script
• I was then able to reproduce without the need to reboot, using the command pwm rate -c 1234 -r 400
• I suspect the pwm_configure_rates to be responsible, but I have not gone into that.

@davids5 any insights from your side?

[davids5]

@bkueng - I will need to dig into this. It sounds different then the causes on the aux pins. Before there were 2 causes. 1) Initializing the pins to inputs during boot. So They could float up and become 1s for the time the OS we inting. 3.1 uS. Creating a long pulse. 2) Once driven low the pins needed to be held low greater than 300 Ms get set to invalid PWM. So that fix was to extend the Low time.

But I think the PX4IO does not know there was a reset. Does that seem correct to you? But possible it is being jerked around via the fw check. I will have a look.

[bkueng]

But I think the PX4IO does not know there was a reset

Well it knows it, but does not react to that. The PWM output keeps running during the reset. There's a small interruption (pwm set to low) when the mixer gets reloaded during bootup. Afterwards pwm rate gets called, which is where the longer pulse happens. It is not related to the reset itself. I also removed the pwm rate call from the startup script, and the long pulse was gone.

[davids5]

@bkueng - My day got away from me. I will look at this more in the AM. I think it my be the UG is forcing an async update on the ARR, but I need to add the instrumentation to trigger on it.

I did see that the in the armed case the mixer is not updated but the rates may be, so that should be looked at as well.

Do you have a clear definition of the states and transitions that should be in effect for the armed and disarmed case when the FMU is rebooted?

I was thinking that in the unarmed case the IO could just reboot and wait in a PWM off STATE for the FMU.

The tricky one is the inair restart. Would you describe how you would expect that to work?

[davids5]

@bkueng - That was it! See #11453. Thank you for sleuthing this out, it saved me a ton of time!