I thought perhaps it was a parameter that didn’t appear until some parameter was enabled, but I couldn’t find it on the parameter list document either.
A previous posts from August 21, 2021, show that BRD_PWM_COUNT has been removed. It references this link:
I’m guessing that the WIKI is simply outdated about this. But as a lot of people will be dealing with this when adopting 4.2.0, it needs to be resolved one way or the other.
Re-reading the wiki, the instructions for copter 4.2 are contained in a NOTE box and a WARNING box.
All the old text for pre copter 4.2 still exists.
It’s unclear if any of the pre copter 4.2 wiki is significant - or if it should be ignored in it’s entirety.
I expect it makes perfect sense to those on the DEV team who developed this change - but its been pretty confusing to me.
As a suggestion, if the part below the NOTE and WARNING boxes only pertain to copter pre 4.2, that text should be identified as such - so that people upgrading to the new firmware can ignore it.
There are other instances of documentation of new functionality being added without revision to the text of the older functionality being modified to take this into account. It’s a source of confusion. The documentation for FFT that’s added to the static filter documentation is another example.
It shouldn’t be a difficult transition, nor one that requires 3-4 separate topics to address.
It looks like you’re using a Cube Orange, so pin 55 corresponds to the output labeled AUX OUT 6, which is configured in ArduPilot as SERVO14 (as documented here).
So, set SERVO14_FUNCTION=-1
If your configuration was working previously, that should be the only required change.
I find that SERVO14_FUNCTION=-1 makes the pre-arm warning go away - but has to be accompanied with SERVO13_FUNCTION=-1 to make the pre-arm warning for pin 54 go away as well. (my camera shutter is using the pin 55 relay)
Using the parameter SERVO_GPIO_BITMASK and checking the servo 13 and servo 14 tickmarks will also cause the pre-arm warnings go away.
I’ve discovered that the relay doesn’t behave properly with the release candidate. Perhaps there’s another parameter I’ve neglected to set.
I’m going to write it up under a separate post - but in a nutshell, the release candidate causes the relay to go high un-commanded.
Using the SERVOn_FUNCTION=-1 method, the relay goes high about every 10 or 15 seconds - causing the camera to start and stop recording on it’s own.
Using the SERVO_GPIO_MASK to enable servo 13 and 14, the camera starts when the firmware boots up - as it did before. (bootloader issue - the relays go high momentarily on boot up) The camera stays on, as the relay doesn’t seem to go high on it’s own. But when I command the shutter causing the relay to go high again, after the camera stops recording, it will start up again - apparently through the relay going high again un-commanded.
None of the un-commanded relay high actuations have associated MavLink messages.
So either I still haven’t set the right parameters, or there’s a bug in the release candidate.
Other than the unrelated boot loader behavior, I have not experienced spurious GPIO behavior (multiple Cubes and H7-based Matek boards).
For the one vehicle where it’s critical, I avoid the boot loader GPIO trigger by using a PWM (RC) controlled relay as a (logic level) power supply switch to my main relay board. It failsafes to off if valid PWM is not observed. I have it set to switch on in conjunction with my ignition circuit command, which coincides with the first time I want to use any other relay.
These parameters are with the servo_gpio_mask settings.
This works better than the servo(n)_function settings.
Using the servo_gpio_mask settings, the relay will go high - causing the camera shutter to release and the video to start recording - until I actuate the camera shutter from my transmitter - which triggers the shutter again and ends the recording. Unfortunately, the relay goes high again un-commanded, in about 10 to 15 seconds after the recording ends.
Using the servo(n)_function method, the relay goes high un-commanded every 10 to 15 seconds no matter what the camera was doing on startup.
Thanks for reminding me about the RELAY_PIN(n) parameters - I remember setting them up when I first configured the relay for the camera shutter - but I’d forgotten where to find them.
NOTE: There is no “RELAY_PIN1” parameter. The fist pin is addressed as “RELAY_PIN”
I set the parameters as you suggested - and still experienced some issues.
It occurred to me that the camera may be playing a role - the camera is heat sensitive - the docs for the camera direct that it must be in motion with the drone within about a minute to avoid over heating.
So I set up a test rig with a box fan to keep the camera cool.
With the extra cooling, the camera behaved much better. I operated the camera in video capture mode for over 5 minutes with no problems.
However - when triggering the shutter to stop recording, the camera would spontaneously start recording again - anywhere from a minute and a half after stopping the recording - to about 3 and a half minutes.
It’s not possible to know if the spontaneous shutter release is caused by the firmware - or the camera. But as no MavLink message is issued, I’m thinking it’s more likely that it’s the camera itself.
Since the recording time doesn’t seem to be affected - at least for up to 5 minutes - it’s less of an issue.
I’ll do some test flying tomorrow and report back.
Definitely sounds like a camera issue. I should think spurious relay output would’ve been seen before by any number of other users. You could try connecting an LED and current limiting resistor to the relay output to help determine root cause.
Thanks for the report and bringing up this issue. There was a Rover user who also hit troubles related to the BRD_PWM_COUNT change so we certainly need to update the documentation and possibly change the SERVOx_FUNCTION default to -1 for the top few channels on some of the boards.
hi @rmackay9,
I’ve been searching for the new method for using brd_pwm_count for the lidar lite v3 and had a hard time finding a simple answer and that’s the numbering for the servox_function. I think this would be so helpful to add an example and a link to this where it explaines the numbering of servox according to the main and aux pins on pixhawk. it can come in the note dialog as this is the explanation which is repeated among hardware setups that need it.
thanks in advance
