I have a second Pi on my BlueBoat that has a control program written in C++. I would like to issue a command to the Navigator to open and close the gripper.
I have done other commands (e.g. testing the motors) via mavlink2rest, by packing json PUT message with the data referred to here: MAVLINK Common Message Set (common.xml) | MAVLink Guide
Does Mavlink2Rest and the autopilot obey other similar commands, such as MAV_CMD_DO_GRIPPER ?
Hi @MikeFair,
MAVLink2REST is a translation layer, it doesn’t actually do anything other than connect to a MAVLink endpoint and provide the data via a REST API.
The autopilot does obey the MAVLink commands that it supports. If you’re using our Newton Gripper then we don’t currently control that using the MAVLink gripper functionalities (although we do intend to move that way in future). For now you’ll need to use MAV_CMD_DO_SET_SERVO commands, targeted at the servo output you want to control. The gripper only supports open/stop/close signals, which you can achieve with 1900/1500/1100µs pulse durations.
As an example, you can set 1900 to open, wait until it’s as open as you want (or allow it to open until it detects it has opened as much as it can), then command a change to 1500 to stop, then 1100 when you want to close onto something/itself) 
Awesome, thanks for the info, @EliotBR !
part of my need is to figure out which commands to use. You said “autopilot does obey the MAVLink commands that it supports” and “MAVLink2REST is a translation layer”
On another post, I learned that blue’s [ardusub page] (MAVLink Support | ArduSub) has the list of commands that the autopilot obeys. Unfortunately, MAV_CMD_DO_GRIPPER is listed here as obeyed incoming-commands, unless I’m reading it wrong.
Does Mavlink2Rest provide any and all commands to the autopilot that it receives over rest? Or are only certain commands forwarded and others dropped?
Hi Mike -
As Eliot shared, anything mavlink associated with “gripper” is not (currently) how you’ll control the gripper - see his response for the details on the set_servo command necessary.
To send commands to the system, pymavlink is likely your best bet! Mavlink2Rest can do this, via POST requests, but we don’t have this very well documented yet…
@tony-white thanks for the pointer. I wish I could go back in time and use python. Ah well. In the meantime, I will use the servo command, not the gripper.
Regarding documentation, the page I linked to, served by Blue, seems to clearly say the that CMD_DO_GRIPPER is supported. But I certainly understand that there are lots of pieces to this puzzle, and some of them have docs that still need an update. Or perhaps I haven’t quite read them correctly. In any case, yall are doing great at providing lots of detailed information, certainly much better than I have done on my products!
You’re not wrong Mike - the page does list that as a supported - however while it is a supported message, the “gripper” in the autopilot isn’t actually linked to anything! This is present only because the functionality was present in ArduCopter.
Gripper control is just done via servo signals at the moment, but a future update to the ArduSub firmware may change that.
PyMavlink or even LUA scripts may be a good option to control your vehicle - a secondary Pi also seems unnecessary and a bit wasteful of battery power, given that BlueOS was developed from the ground up to support control software running alongside it in parallel (rather than on a separate single board computer…)
Cross-compatibility is always challenging to document clearly. In this case, there are various types of grippers that exist in the world of robotics, and our Newton Gripper is not currently one that the ArduPilot firmware family knows how to control when receiving that command - i.e. support of a MAVLink message does not guarantee support of a specific device.
I understand that can be confusing and unintuitive, but would also highlight the note at the top of that docs page:
MAVLink2REST is not a MAVLink router - it’s an API wrapper. It doesn’t try to do any filtering - just responds to REST API requests with information from its connection to a MAVLink network, and passes information from other REST API requests back to that MAVLink network.
Whether a particular component receives and handles a MAVLink message depends on how the message is targeted (e.g. the message should be either targeted to the specific component ID, or sent as a broadcast), and whether all parts of the connection are using the same system ID (MAVLink2REST presumably just transmits using the system ID of its MAVLink connection).
1 Like