We are building a few unmanned vehicles (UAV/UGV) and have not been able to successfully use a Gamepad/Joystick with QGroundControl. We have tried numerous configurations and all result in failed MAVLink comms, usually:
“Vehicle 1 did not respond to request for parameters. This will cause QGroundControl to be unable to display its full user interface”.
This loosely translates that QGC cannot send/receive MAVLink commands properly when the hand controller is plugged in.
Here are all my test setups resulting in the same error:
Windows laptop + PS2 controller -> USB Pixhawk CUBE Black (ArduRover 4.0.0)
Macbook pro + PS2 controller -> USB Pixhawk CUBE Black (ArduRover 4.0.0)
Samsung Galaxy Tab + Logitech F310 -> USB Pixhawk CUBE Black (ArduRover 4.0.0)
Windows laptop + Logitech F310 -> USB Pixhawk CUBE Black (ArduRover 4.0.0)
Samsung Galaxy Tab + Logitech F310 -> USB Pixhawk CUBE Blue (ArduRover 4.1.0)
Windows laptop + Logitech F310 -> USB Pixhawk CUBE Blue (ArduRover 4.1.0)
Samsung Galaxy Tab + Logitech F310 -> Telem radios Pixhawk CUBE Blue (ArduRover 4.1.0)
Windows laptop + Logitech F310 -> Telem radios Pixhawk CUBE Blue (ArduRover 4.1.0)
Without the gamepads plugged in everything functions normally. However, our application will not have the ability to use a standard RC radio so we desperately need to figure out why the gamepads cause this fault with communications.
I wonder if you could try using Mission Planner with a gamepad to see if this works? I suspect it will and although I know this is not the final configuration you want to use it will narrow down the problem to a compatibility problems between AP and QGC.
@rmackay9, yes Mission Planner work with either joysticks on our Windows systems.
The main reason we need QGC is we are running on an Android Galaxy Tablet and driving it via IP streaming video (RTSP which works great btw!). I am currently digging through the QGC Master branch code to see if there is something that jumps out as a conflict between the hand controller initialized and MAVlink.
Some additional information, if I plug the hand controller in after the link has been established, I can see it under the Joysticks panel. I can move the sticks and press buttons and they register on the screen. However, if I try to then ARM/DISARM, I get a follow up error that the system did not respond to an ARM_DISARM.
If you need some more systematic tests to help focus the area where the problem exists, please let me know. I suspect it to be some loop that possibly hangs/hogs MAVLink processing since it’s now trying to send telemetry packets out faster with the hand controller.
ok, great thanks. I think it’s unlikely to be a bandwidth issue, it’s much more likely to be a compatibility issue between AP and QGC. I suspect others on the dev team are already aware of the issues so I’ll ask around.
I think we need to get some logs to dig into this more. Any chance you could provide an onboard log and a tlog? Not to be too picky but if possible short logs just showing the arming problem might be good. Perhaps also move the stick around a bit so we can see in the AP logs if those messages are getting through. It may be neccesary to set LOG_DISARMED = 1 to get the vehicle to save an onboard log while it’s disarmed.
… or maybe I’ll need to setup QGC on my PC with a joystick to resolve this… I’m sure we can, it’s unlikely to be a big problem actually.