in the course of uavcan-izing my world, i.e. my uc4h project, I recently also added uavcan support to the STorM32 gimbal controller, both in software and hardware. It’s kind of useless, since there are no uavcan messages yet supported by AP, and Luis and Pavel asked me for suggestions. I was (and am) quite hesitant, since it’s a so diverse topic, but I probably should leave some comments.
I’ve reviewed the history of AP’s serial/Mavlink gimbal support and analyzed the status quo, went through what I did in betacopter, and, based on the refreshed memories, tried to come to an opinion as to where uavcan gimbal support might go. Here it is:
I think the discussion would have to first determine what kind of support AP really wants to provide (or can provide).
I think it’s a nontrivial question, and a key one. As a rough classification I would see three kinds:
(A) Generic support: One driver for all.
This essentially would be a mirror of what is there for Mavlink. The Mavlink support, as detailed here http://ardupilot.org/dev/docs/code-overview-adding-support-for-a-new-mavlink-gimbal.html, boils down to one essential message, namely a message to control the orientation of the gimbal (COMMAND_LONG : MAV_CMD_DO_MOUNT_CONTROL). (heartbeat and parameter messages do not count, and REQUEST_DATA_STREAM is provided anyhow).
So, it should be extremely simple to achieve this level of support. Emission of a uavcan attitude message is already in the making (PR #6528). For the orientation control one could use a revised version of uavcan.equipment.camera_gimbal.AngularCommand (it probably should allow also Euler angles, and might better mirror the Mavlink modes). The driver would be essentially copies of the available drivers.
The STorM32 controller also allows the emission of MAVLINK_MSG_ID_ATTITUDE and/or MAVLINK_MSG_ID_MOUNT_STATUS messages, which can be quite important for all those applications which need to know the actual gimbal orientation. So, although not part of the “AP standard” one probably would want to add this, and ask the gimbal to emit a corresponding uavcan message. This message could be also uavcan.equipment.ahrs.Solution. A slight disadvantage of it might be that it would not be easily clear to outsiders that this is the gimbal attitude (they would have to infer that by maintaining a list of the ids), but drafting a new message shouldn’t be a biggy.
I don’t see any concept so far for handling the parameters of uavcan nodes. This topic would anyhow go beyond just gimbals, and thus might be left out here.
In conclusion: This should be extremely simple.
(B) Specific support: One driver for each.
Here one would essentially give up with the idea of a “standard”, and allow/promote the integration of drivers for each gimbal type.
I think it is hard to argue away the fact, that, for the serial/Mavlink gimbals, there is a SoloGimbal driver, two STorM32 gimbal drivers, and one Alexmos gimbal driver, which in fact are two since Alexmos suggests using the (non-serial) STorM32 gimbal driver. So, there are at least 3 non-generic, gimbal specific drivers. This might be a historical fluke, or for good reasons, pl decide yourself.
When it comes to can/uavcan, one also should add the Gremsy gimbal.
Personally I think that this approach has many virtues.
In order to avoid a flood of uavcan messages, one could draft two simple container messages, one broadcast and one request/response. With container I mean that it is just a uavcan wrapper to whatever protocol the gimbal is using. For instance, the STorM32 provides 0xFA messages, and one could just use that byte stream as the payload of a uavcan message. This concept would, again, have many virtues (I’ve added it “inoffically” to Mavlink, see COMMAND_LONG - MAV_CMD_TARGET_SPECIFIC). It would allow the gimbal driver to do “whatever it wants”, i.e., make use of any feature provided by the gimbal, and this in a future-proof way (e.g. no need for new messages when a new feature is added, only updated driver). It also would make it easy for gimbal developers to implement (since they just have to unpack/pack what they have already), and would be resource efficient on the gimbal side. It probably would be useful to add a “node type” field to that uavcan message, to make it easier to identify the origin of the payload content.
It should be obvious that this set of messages could be beneficial not only for gimbals, but many other nodes.
Nevertheless, AP should define a set of messages, when it comes to information on the gimbal, i.e., data which one might want the gimbal to emit to the outside. The prototypical example would be the gimbal orientation. It obviously would be beneficial if all gimbals would emit their attitude/orientation in identical messages. So, AP should define them.
© Specific support, plus a rich driver API.
As before, one would give up with the idea of “one-for-all”, but would provide a rich API, which any driver can make use of to achieve more advanced functionality, or a “smart” integration. The hard job could be left to any volunteer who wants to write the driver, but she/he would be significantly supported by the API.
I mention, that, as far as I know, a precursor is already in AP for unix boards, where “apps” can be “installed”, and that this was also envisioned for Pix boards but never materialized. I would not actually have such apps in mind here, but hard-coded drivers. I suspect that they could achieve better performance figures (e.g. timing accuracy) than apps.
Currently, the Mounts, on which the gimbal drivers are based, have only very limited access to information and possibilities to affect the flight controller. In order to give you a better feel for what I have in mind here, I’d like to briefly describe what I did in betacopter, as an example.
- Send status messages to the GCS at startup, to inform the user that a gimbal was detected, it’s version, and that it started up correctly.
- Link into the pre-arm and arm test sequences, in order to allow the user to ensure that the gimbal is fully functional before lift-off. This included reading the appropriate status messages from the gimbal.
- Forward the raw rc inputs to the STorM32, so that users can control via the transmitter all the “Functions” which the STorM32 provides, such as switching pan-hold modes, starting scripts, etc.
- Link into the camera trigger functions, to forward the camera trigger to the STorM32, to make use of the STorM32’s integrated camera remote control feature.
- Allow the control of the camera orientation by the transmitter signal, in order to make better use of the STorM32’s own min/max, speed, and acceleration limiters.
- Allow to recenter the camera, also in flight.
- Send the flight controller attitude quaternion plus other dedicated info (yaw input rate, EKF status, etc) to the STorM32, paying attention to tight timing.
I easily could extend the list by further wishes, or, as I would call them, cool options (e.g. allowing to inject dedicated waypoint messages, opening of a tunnel to a PC,…).
IMHO, this kind of support is soo much more 2015-ish.
Only you can decide. And only you decide.
Note added in proof: I just now got a 4 days old message by Luis, where he suggested that one could, as a start, look at what other systems do, specifically https://developer.dji.com/onboard-sdk/documentation/introduction/homepage.html. This is obviously a good idea, but I have not rated that in. Thx Luis.