Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sub: Rework joystick input and pilot input in general #9808

patrickelectric opened this issue Nov 15, 2018 · 3 comments


None yet
4 participants
Copy link

commented Nov 15, 2018

Moved from: bluerobotics/ardusub#158
Original author: @jaxxzer

Feature request

We need some sort of input abstraction layer that rc input and mavlink/joystick input sit on top of.

[ ] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[ ] Rover
[x] Submarine

@IamPete1 IamPete1 added the Sub label Nov 17, 2018


This comment has been minimized.

Copy link

commented Jan 3, 2019

Our inputs are limited to 4 analog axes and 16 digital buttons, this is very constraining. I would like to support an arbitrary number of analog/digital inputs with flexible assignments to things like inputs, input trims, lights channels 1, 2, 3... multiple camera gimbals, multiple manipulator joints etc.


This comment has been minimized.

Copy link

commented Jan 3, 2019

couldn't a AP_Joystick class be the solution ? like ask in #10147 ?


This comment has been minimized.

Copy link

commented Jan 8, 2019

We currently have:

  • Receiver input

It would be good to have some frontend abstraction that handles them all. However, there are limitations to all of these that make them unsuitable for Sub.

  • They only support x number of analog and/or digital 'channels'. I would like to have any arbitrary number of inputs that can be assigned/handled.
  • There is a difference in the operation of eg a two position switch, a three position switch, and a momentary button. I would like to support them all.
  • The joystick buttons and 'switches' are handled on the autopilot side. This has lead to complicated parameter setups and handling in the code. I think that these things should be handled on the GCS side. QGC currently does this for other vehicles, by processing the button input and sending some MAV_CMD that the user assigns to the button. This is my preferred situation, but we need to add mavlink messages to support the button functions that we have in ArduSub.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.