The moment I connect power and until the board has booted, the servos are moved to extremes and are probably going to rip apart the wings if it continues doing it everytime I power the board, after about 10sec when the Pixhawk has booted the servos go to center.
From searching, this seemed to be a problem a few years ago and was considered a normal by some, with the solution being to power the tx before powering Pixhawk, but I have also done that and it doesn’t help either, probably because of the way my TX/RX works, but still it shouldn’t happen since technically RC is not needed.
BRD_SAFETY_MASK is not in play here since the servos are disabled when the board has booted and the safety button must be pushed to enable them.
If there is no solution I consider making a 555 delay timer to switch the BEC power on after the boot has finished.
@oscarCK I tried to reproduce this on a Pixhawk1 with plane 3.8.0. I captured a logic analyser trace for the first 5 channels on power on until it had fully initialised. The trace showed channel 1 at 1500 and channel 3 at 1100, which is what is expected with your parameters.
I tested with no receiver connected. Perhaps that is the difference? What type of RX do you have? Is the TX on or off at power on?
I have tried with and without a receiver, I am using ULRS, now that I have understood how the bitmask actually works I can also see why channel 1 was at 1500 (since I had written 1), I also checked all the channels with a logic analyzer today, and can see the same results, and I might have found the culprit, the moment power is connected there is a 1us spike on all channels until it has initiated and gives the set signals. Can’t remember the bitmask value for when the servos returned to center after initializing.
While I was testing my servos (Corona DS-843MG) with an arduino servo test sketch before installing them I noticed that if I made a very quick signal connection-disconnection the servo was stuck to its min position until it was given another signal, like the 1us spike that is given during power on.
Shane what servos are you using? I also tried the BRD_SAFETYENABLE set to 0 and didn’t fix the problem since the spike is probably a hardware related issue. Using a Px4Pilot from Hobyking btw.
So the only way I can see it being fixed is giving one pulse of 1500 to all channels on power on before using the parameters but is that even possible before Pixhawk has initialized?
ok, thanks for investigating.
To eliminate this completely we’d need a bootloader change I think. Otherwise no matter what we do in ArduPilot that spike will happen.
Interesting that it is 1us for you. On my board I see a 0.2s spike, which is so long I’d expect no servo to react to it.
How do you feel about experimenting with bootloader changes?
only if the pulse is valid. A 1us pulse is not a valid control - it should be treated as noise by a servo and ignored.
If it was 700us then I’d understand it. For 1us, its crazy.
Oh sorry, I confused 1us with 1ms. They should be missing a range check in the servo uC code. Anyways, aren’t all the GPIOs of the Pixhawk microcontrollers supposed to be tri-stated until a correct initialization is done? Is there any buffer circuit between uC and servo outputs?
I’m willing to test the bootloader changes if there is a possibility fixing it, even though I have already made a custom power distribution board with a delay on timer for the BEC power, but it’s an intermidiate circuit which can be left unused.
Also the 1us pulse is not in sync with all channels, it seems to be advancing at about 3us as it goes from the first channel to the next one.
can you check first that it is definitely in the bootloader. Do that by unplugging the board partway through a firmware load. That will force the board to stay in the bootloader (as it won’t have a valid firmware to run). Then get a capture and confirm behaviour.
Can you also please update to the latest bootloader? To do that open a nsh shell (using nsh over mavlink) and run:
bl_update /etc/bootloader/fmu_bl.bin
Ok I “bricked” it to capture the channels when there is only the bootloader, reflashed plane did the bootloader update and loaded the same parameters (the safety button is disabled in these parameters).
yep, just been busy
So it looks like it is pin initialisation in the bootloader. The weird thing is that I don’t see it.
hmm, actually, I just realised you’re probably testing on the IO channels on the pixhawk, not the FMU channels. That means it is the bootloader on the IO microcontroller not the bootloader on the FMU that we need to look at.
Can you try on the AUX channels? See if they have the same issue for you.
I just did a capture on my Pixhawk1 and I don’t see the same result as you. I see a pulse on the IO channels on startup, but it is 0.2s long, way longer than any servo will react to.
ok, then it could be the IO firmware. Do you have a safety switch installed? Can you test with that held on power-up, while also having no firmware on the FMU? Holding the safety button while powering on the IO microcontroller will prevent the bootloader from loading the IO firmware.
