How do I use MAVLink Endpoints to get gamepad data?

[MarkFromCanada (Mark)]

Hi Rafael,

Thanks for your help

@rafael.lehmkuhl

how critical it is for you guys to keep using MAVLink MANUAL_CONTROL messages for the commands part?

It’s definitely the preferred path. The alternative would be to use an iframe widget which would capture and send the joystick data via a websocket, but I thought that since joystick interfacing was built in, it wouldn’t be ideal to reinvent the wheel here.

The same goes for populating existing widgets with my own mavlink data, I could sidestep mavlink and just use a websocket+iframe with custom html widgets, but I want to make use of the widgets that you guys have already developed.

@rafael.lehmkuhl

right now BlueOS does not support having the MAVLink router running without an autopilot running

Good to know. This might explain why I can’t send mavlink messages to cockpit, but even with the SITL on, when I try to inject mavlink messages into the stream it crashes the autopilot. Would instantiating a router along side my python scripts allow me to send mavlink mesages to cockpit, to update it’s widgets?

@rafael.lehmkuhl

can you clone the Cockpit repository and test this PR ?

For sure! I tested it this morning. When autopilot was enabled, it behaved exactly like the master branch. When I stopped the Autopilot, that’s where I noticed a difference.

When the autopilot is stopped, every time I reload the cockpit tab, this PR version of Cockpit sends an updated MANUAL_CONTROL message exactly once, but doesn’t continue to send repeatedly until autopilot is started up again.

For contrast, the master branch of Cockpit wouldn’t send messages at all on reload if the autopilot was off.

This makes me wonder… Is it because the mavlink router isn’t running? But then how would one message still make it through each time the cockpit web client connects?

It does seems like a step in the right direction though.

@rafael.lehmkuhl

For commands (apart from the axes) I would think that using the COMMAND_LONG message would be much better for you guys,

Can I just use common messages like AHRS to update the compass widget, like how ardupilot does? Or do you mean I would use this for sending data from the GCS to the robot?

[rafael.lehmkuhl (Rafael Araujo Lehmkuhl)]

It’s definitely the preferred path. The alternative would be to use an iframe widget which would capture and send the joystick data via a websocket, but I thought that since joystick interfacing was built in, it wouldn’t be ideal to reinvent the wheel here.

The same goes for populating existing widgets with my own mavlink data, I could sidestep mavlink and just use a websocket+iframe with custom html widgets, but I want to make use of the widgets that you guys have already developed.

Definitely better to reuse than as much as possible.

Good to know. This might explain why I can’t send mavlink messages to cockpit, but even with the SITL on, when I try to inject mavlink messages into the stream it crashes the autopilot. Would instantiating a router along side my python scripts allow me to send mavlink mesages to cockpit, to update it’s widgets?

Instantiating the router by your own would already solve the problem, yes, but another nice alternative would be to do a PR on BlueOS adding this feature (allowing disabling the auto-restart feature on the AutopilotManager)

For sure! I tested it this morning. When autopilot was enabled, it behaved exactly like the master branch. When I stopped the Autopilot, that’s where I noticed a difference.

When the autopilot is stopped, every time I reload the cockpit tab, this PR version of Cockpit sends an updated MANUAL_CONTROL message exactly once, but doesn’t continue to send repeatedly until autopilot is started up again.

For contrast, the master branch of Cockpit wouldn’t send messages at all on reload if the autopilot was off.

This makes me wonder… Is it because the mavlink router isn’t running? But then how would one message still make it through each time the cockpit web client connects?

I will take a look, but it’s probably the router indeed.

Can I just use common messages like AHRS to update the compass widget, like how ardupilot does? Or do you mean I would use this for sending data from the GCS to the robot?

For sending data from the vehicle to the GCS, I recommend using the dedicated messages (like the AHRS). The COMMAND_LONG message would be to send commands from the GCS to the vehicle indeed.

[rafael.lehmkuhl (Rafael Araujo Lehmkuhl)]

Passing by here to say that Cockpit v1.18.0-beta.5 now includes support for receiving generic data via WebSocket, which makes the whole process of sending and showing user-generated data in Cockpit, be it from the vehicle or another system, much easier.

I’ve added an example extension here so anyone can copy/fork from it to create its own. It’s as simple as running a WebSocket server and sending data through it, which can be accomplished in a dozen lines of Python, which can be seen in the example below:

import asyncio
import websockets

async def handler(websocket):
    while True:
        await websocket.send("variable_name=variable_value")
        await asyncio.sleep(1)

async def main():
    async with websockets.serve(handler, "0.0.0.0", 8765):
        await asyncio.Future()

if __name__ == "__main__":
    asyncio.run(main())

The most important part for someone spinning up its own extension is to put the Network Mode on Host mode, which is done with the following permission:

{
  "HostConfig": {
    "NetworkMode": "host"
  }
}

This allows the extension to bind the WebSocket server port and receive Cockpit connections.

One can send all types of primitive data, like strings, booleans and numbers. It’s as simple as sending the variable name and value separated by an equal sign, each par in its own message.