Px4-autopilot: Gimbal control via SBUS OUT

[dakejahl]

Describe problem solved by the proposed feature
A lot of gimbals use SBUS. We have an SBUS OUT, we should support gimbal control via SBUS!

Describe your preferred solution
If someone has code that would be great, I'd help get it pushed through. If not, I'd like to implement this.

[mwiatt]

This would be fantastic. The current SBUS implementation is limited to 8 channels by this call:

https://github.com/PX4/Firmware/blob/1dd6b6a5058199ea6bbf1e2321010abe88a656ee/src/modules/px4iofirmware/mixer.cpp#L377

where PX4IO_SERVO_COUNT is limited to 8:
https://github.com/PX4/Firmware/blob/1dd6b6a5058199ea6bbf1e2321010abe88a656ee/src/modules/px4iofirmware/px4io.h#L65

It was just a few days ago that I was hoping that I could amend the main mixer to include gimbal outputs. I am using a hexacopter so I only have 2 channels left (of the 8 available) on the main PWM channel and I need more than 2 to control all of the gimbal functions.

[mwiatt]

It doesn't look like the sbus.cpp code would need to be touched as it already seems to support the 16+2 channels supported by sbus:

https://github.com/PX4/Firmware/blob/1dd6b6a5058199ea6bbf1e2321010abe88a656ee/src/lib/rc/sbus.cpp#L237

[julianoes]

I thought this works if you just select MNT_MODE_OUT to AUX.

What gimbal are you trying to control?

[dayjaby]

The sbus out works only for the main outputs, not the aux outputs. Our solution was to attach a pwm to sbus converter to the corresponding aux channels.

[mwiatt]

I am trying to control a Gremsy gimbal. Gremsy is having some Mavlink issues right now so I was hoping to fall back to another interface. Sbus was my first choice. I didnt even try it after I saw the only call to the sbus output function was in the main mixer and limited to 8 channels.

[mwiatt]

The sbus out works only for the main outputs, not the aux outputs. Our solution was to attach a pwm to sbus converter to the corresponding aux channels.

Exactly what I am going to have to do. My gimbal has sbus and ppm inputs, neither of which are supported by PX4/pixhawk. Only solution is to use a PWM to PPM or SBUS converter.

[dayjaby]

@mwiatt

Is the PR https://github.com/PX4/Firmware/pull/12865 not working for you? Controlling gremsy via sbus has some other disadvantages, like not being able to control the yaw axis properly (at least the Pixy F)

[mwiatt]

That PR is for the Pixy_F. Gremsy decided to use full scale angles on the current version of the S1 firmware but with the opposite sign convention of that used by PX4/ardupilot. They are supposed to have a new firmware out for me to test in a week or so. I ended up building my own PX4 firmware with the Mavlink angles multiplied by -1 as a temp workaround since I didnt have any other options (other than the PWM converter).

[dakejahl]

Here's my wishlist for SBUS OUT if anyone cares

• SBUS OUT is its own unique bus (as far as PX4 firmware is concerned), with an optional parameter to enable SBUS IN to mirror onto channels 1-8 on SBUS OUT.

• SBUS OUT is controlled and configured via a "driver" on the FMU. This would be similar to how pwm uses px4_ioctl to send commands to the IO processor.

• Devices that wish to use SBUS OUT (like a gimbal controller module) would inherit/compose from the SBUS OUT driver, since this is a unique resource, yet you could enable different usages of the SBUS out simply by starting different drivers in the startup scripts.

@julianoes I figured I'd move this out of slack. :grin:

Why
I think it's silly that we _must_ mirror SBUS IN onto SBUS OUT. These are two physical UARTs. Also enabling AUX passthrough just seems like a hack. We now share the concept of an SBUS bus between an input and an output (as far as the software is concerned), AND we use up physical IO pins for no reason.

If I've got anything wrong here someone please correct me. Thanks!

[dayjaby]

Or have a third mixer file? Main, aux, sbus ... this would give the highest flexibility.

[JacobCrabill]

The idea of a third mixer file is interesting... allowing the outputs to PWM vs. SBUS to either be mirrored or independent would be useful.

A relatively simple "hack", though, to get the extra SBUS outputs is to increase the size of the registers in px4iofirmware to the number of SBUS outputs desired, increase PX4IO_ACTUATOR_COUNT accordingly, and make sure that up_pwm_servo_set only gets called for 8 outputs, while sbus1_output / sbus2_output gets called for all outputs. You'll also have to modify the px4io driver on the FMU processor to make use of (or at least be aware of) the larger number of actuator outputs, and modify the pwm systemcmd as well if you want to set min, max, failsafe, etc. values on the channels beyond MAIN8. It's not too many changes. Once that's done, you can then append all of the additional outputs to the MAIN mixer; the one caveat (as mentioned above) is that the first 8 MAIN outputs will be sent out via both PWM and SBUS, rather than being fully independent output channels.

[LorenzMeier]

I've been watching this thread with a mix of horror and remorse: I do really care about supporting you guys to have the gimbal working for you, but really, this is all about Gremsy being MAVLink spec compliant. I will talk to them.

[mwiatt]

While the issue did come to light because of desire to control the Gremsy gimbal, it does highlight the shortcomings of the SBUS output implementation in PX4.

Currently, PX4 just mirrors the 8 PWM channels on the main output. Those would typically be used for motor control. There are very few, if any, ESCs that use SBUS so this isn't particularly useful. Additionally, if SBUS ESC's are used, the main PWM outputs are tied up because they have to mirror the SBUS outputs. In terms of IO resources, this is very wasteful.

Additionally, SBUS allows for 16 channels. PX4 is only using 8 of those.

I think that a 3rd mixer for the SBUS output would be great. It would be easily understandable to anyone familiar with PX4 IO and mixers. The ability to pull from any control group and then output the signals in any order with the capability to scale them would give a ton of flexibility. It seems like it would fit right in with "the way things are already done".

Also, with a SBUS to PWM converter, any Pixhawk based flight controller with an SBUS output could gain another 16 channels of PWM based IO for servo, ESC, etc. control.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[ayberkozgur]

I'd like to reanimate this issue, having a standalone SBUS out channel with a mixer file is very interesting for us. Is there any plan for such a feature?

[JacobCrabill]

I've actually been thinking about another application along these lines too: Having a UAVCAN mixer. Both would require similar modifications, I think. Alternatively, I'm still very interested in doing away with mixer files entirely and having all outputs mapped via parameters... this would completely remove the need to recompile firmware or futz with mixers on SD cards to swap the order of a couple outputs.

[vaibhavviswanathan]

Following up here -- is the Gremsy gimbal now compatible?

[dakejahl]

@vaibhavviswanathan that's a question for Gremsy, you should test it out and report back. They sent me a beta version of firmware that fixed the mavlink issue back in November, so it's probably been fixed in their release firmware by now.

[asaba96]

@dakejahl so is there still no SBUS out support to enable using the Gremsy gimbal without relying on another mavlink connection?

[dakejahl]

@asaba96 That's correct

[OskarPepryk]

I have tested the code changes @JacobCrabill mentioned. I got working at most 10 SBUS channels. The limit seems to be the memory available on IO processor. Loading large mixer files is basically impossible on v1.11. Even some 8-output mixers eat up all the IO memory. I will also try testing it on v1.9.2.

The other workaround would be to implement SBUS output on one of the FMU PWM outputs.

Edit: In v1.9.2 I got 16 SBUS channels working, using helicopter mixers.

[coderkalyan]

My team is acquiring a gremsy T3, and while I'd like to be able to speak MAVLink to it, I'm running low on UARTs on my FC. While I could probably wire the gimbal to my companion computer and do some routing, I'm considering using SBUS out instead. @dakejahl @OskarPepryk @JacobCrabill Anything I can do to help get this to a working state?

[OskarPepryk]

@coderkalyan
I never worked with gimbals so I don't really understand the original issue. Is it not possible to control gimbal using a mixer file with appropriate inputs (actuator_controls_2)?
You might checkout my fork which implements 16 channel SBUS output. It's not tested in flight and is based on old but stable PX4 v1.9.2. I think that the diffs can be applied to current versions as well.
After loading large mixer files, check the remaining IO cpu memory using "px4io status" command. There are no warnings if loads too big of a mixer.

[bys1123]

I guess we need this feature too in china. There is lot's of sbus-controlled gimbal in the market.