Uavcan Gimbal xyz

Hey Folks,

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.

Final:
Only you can decide. And only you decide.

Cheers, Olli

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.

no comments, no suggestions, silence for two weeks

so I decided to define required messages such as to reach a “fully functional Uavcan support” of the STorM32 gimbal controller, and here it is

the first uavcan gimbal

I mirrored, kind of, how it’s working with Mavlink, so it should be a piece of cake to modify one of the existing mount backends to support uavcan
for the messages see http://www.olliw.eu/storm32bgc-wiki/Uavcan

:slight_smile:
Have fun,
Olli

2 Likes

Olli, I wasn’t aware of this post until now because I’m not subscribed to the forum. Since this is a UAVCAN-related matter, perhaps it would have been met with more attention (at least from myself) if you posted it via the UAVCAN mailing list instead. :wink:

Of the approaches you helpfully proposed, only the first one is viable. I have attempted to explain why vendor-specific data types will never work well in this post here:
UAVCAN GPS get_lag().

I suggest we stick to quaternions rather than Euler angles because quaternions are more versatile and therefore they are used almost everywhere in UAVCAN. So we should keep using them for the sake of consistency.

You seem to be right at choosing float32 instead of float16. My quick analysis here shows that a float16 based quaternion offers a rather low angular resolution of about 0.3 degrees.

Besides the direct orientation commands, the standardized gimbal control interface should support Geo POI mode, where the gimbal is supplied with a geo coordinate of interest and keeps the camera pointed towards it. To support this feature, the gimbal needs to be aware of its own geo position and orientation; thanks to UAVCAN, both can be easily extracted from the bus.

Having two separate commands AngularCommand and GEOPOICommand was a questionable idea (GEO is supposed to be Geo, another mistake). They should be merged into a single command message with a union inside of it.

What is your opinion on the gimbal status message? The current definition reports the gimbal orientation in the body frame, but I see some value in using the world frame instead. The advantages of the world frame are that it would be consistent with the AHRS solution message. The benefits of the local frame are that it would work well with gimbals that deduce their orientation from the encoders rather than from an independent IMU.

We probably should add a set of camera command messages as well, which should probably go in a separate namespace, since I would consider the gimbal and the camera to be distinct and independent entities. What options should be necessary there? The basics such as the following come to mind:

  • Take a photo.
  • Record video (note that we need to keep the protocol stateless, hence “record video” as opposed to “begin recording”/“stop recording”).

The general configuration options, such as exposure settings, probably would not require any separate interface, because there is already the standard configuration management API that should suit the task splendidly. Perhaps we should define a set of standardized names for camera-related configuration parameters, such as exposure settings, compression parameters, et cetera. Although that can (and should) be postponed for now.

Pavel.

Hey Pavel

I admit that I’m constantly puzzled as regards to where to post a topic best … I posted it here since IMHO it’s most related to AP. They have to implement it. Anyway.

As I’ve explained in the thread you linked to, I don’t find your arguments in favor of (A) convincing. I would have very strongly hoped for ©. Approach (A) is - to me - really so last century. But as said, it’s not upon me to decide anything.
(I anyhow will do whatever I want whenever I want to do whatever I want LOL, it’s clear now that there has to be an updated betacopter)

Yes, this was the reason why I chose float32.

Quaternion or Euler doesn’t matter much. I would though never ever use float for quaternions. What a waste. Quaternions need a slightly more precise definition to be unambiguous.

I understand the argument for Geo and world frame. However, it’s not only about extracting the info from the bus, but also requires maintaining ghost states. I actually have traces of this in the code (called STorM32 Link and tracking), but I’m not hyper active here. That is, STorM32 likely will not support this for a long while (and especially not for the sole reason of satisfying a standard, if, then only for other benefits this may have).

In contrast to orientation I don’t consider Geo POI the job of a gimbal, it’s clearly the job of a flight controller, or whatever external unit. I mean, in your proposal one sends a POI to the flight controller, which forwards it to the CAN bus together with its own geo, which both are grabbed by the gimbal to maintain an internal ghost state just to properly subtract the two positions - instead of just taking the received POI and doing the subtracting right away in the flight controller … there are better ways to waste resources.

For broadcast messages I think I always would opt for two instead of one union-ed one (unless they are really the same basic data). Acceptance filters are a great thing. Angular and Geo are IMHO different data.

I would find camera messages exciting. You may have noticed that the STorM32 has some integrated camera functionality. I also would separate it from the gimbal (I would thus rename “camera_gimbal” to “gimbal”, who the heck knows what the gimbal carries).

Much more exciting I would however find an option to trigger STorM32 functions. :wink:

The “general configuration options” I would consider a perfect example of where a standard doesn’t make any sense, and gives away benefits. No comment.

:slight_smile:

Cheers, Olli

In contrast to orientation I don’t consider Geo POI the job of a gimbal, it’s clearly the job of a flight controller, or whatever external unit.

By the very definition, the job of the flight controller is to fly the aircraft; whereas the job of the gimbal controller is to control the gimbal. Rendering the flight controller responsible for controlling secondary peripherals such as gimbals violates the principle of separation of concerns. It is unfortunate, but there were strong historical reasons for that, which I recognize. It doesn’t mean that it has to stay this way. Besides, the Geo POI mode would remain not a requirement of the protocol but an option, alongside the direct control mode that you’ve implemented in STorM32.

For broadcast messages I think I always would opt for two instead of one union-ed one (unless they are really the same basic data). Acceptance filters are a great thing. Angular and Geo are IMHO different data.

Both angular and Geo are command messages, so it’s natural that the gimbal controller would want to subscribe to both, even if some of the modes are not implemented. Although it is really a non-issue, and we can easily spare an extra message ID to avoid having this argument.

I also would separate it from the gimbal (I would thus rename “camera_gimbal” to “gimbal”, who the heck knows what the gimbal carries).

Makes sense. There should be uavcan.equipment.camera and uavcan.equipment.gimbal.

Much more exciting I would however find an option to trigger STorM32 functions.

Perhaps you could post a comprehensive list here so we could eye it together? Better yet, I propose to move this discussion to the UAVCAN mailing list if you don’t mind, because people interested in UAVCAN in general would never find this discussion here.

Thanks.

[quote=“Pavel_Kirienko, post:5, topic:19071”]
By the very definition, the job of the flight controller is to fly the aircraft; whereas the job of the gimbal controller is to control the gimbal. Rendering the flight controller responsible for controlling secondary peripherals such as gimbals violates the principle of separation of concerns.[/quote]If that would be the only point to consider I would agree. However: A gimbal, as any other piece of electronics, has natural access to only that information which it has sensors for. Position sensors are NOT among the gimbal’s sensors (in contrast to attitude). Gimbals are about attitude. So, neither the flight controller nor the gimbal controller would be responsible, and one can throw around now the responsibility, but everyone rightfully could decline to take it.
From a practical perspective it however doesn’t make any sense to require the gimbal to do it, for the reasons I’ve explained.
Also, at least with AP, one really can’t argue that it would shy away from taking over controlling secondary peripherals, it in fact does so for quite many (it even does half of Solo’s gimbal job, doesn’t it ;)). This makes the separation argument somewhat artificial. IMHO.

But angular and geo are not related data. Following your argument one should put also e.g. all protocol commands in a union, right? I would maybe argue differently with requests, but with broadcast we shouldn’t have a shortage of IDs anytime soon

(I’ve said something similar before, it’s kind of weird how orthogonal our thinking is, just few lines before you strongly argue in favor of a clear logic boundary, while few lines later I do LOL).

As regards the functions and other stuff of STorM32, here’s the set of features one would want to support: http://www.olliw.eu/storm32bgc-wiki/Serial_Communication#Serial_Communication_-_RC_Commands
I accomplished their complete support with the simplest and most versatile approach I could see … a tunnel … I’m too limited in mind to imagine better alternatives.

All thanks go to you.

Cheers, Olli

A gimbal, as any other piece of electronics, has natural access to only that information which it has sensors for. Position sensors are NOT among the gimbal’s sensors (in contrast to attitude).

This is true only as long as you’re confining your thinking to old approaches that do not make use of the concept of a proper data bus. Being connected to UAVCAN, your gimbal has natural access to all of the onboard sensors that are present on the bus. Hence, it knows the orientation of the aircraft, it knows where the aircraft is, and so on. My argument about the separation of concern still holds.

Fun fact: PX4 and APM would relay GNSS data to the UAVCAN bus if they detect that the bus does not have a GNSS receiver. Guess why do we need this? :wink:

for a camera to catch it
or any other node who want to know it
and if you have a gimbal which likes to get it, to make it happy

by the very same argument you should actually conclude that ALL camera functions are also the gimbals job, interesting that just previously you concluded that gimbal and camera should be separated

also strange that AP has a heck of camera trigger functions, all cameras should do, and should have been required since ever to do, all that themselves

it’s one thing to have a gimbal which likes to digest the camera functions and another thing to claim that all camera functions must be done by the gimbal because it carries the camera

btw, the flight controller controls the copter which carries the gimbal which carries the camera …

you are inconsistent and arbitrary in your logic

that’s btw why we “often” come to different conclusions :slight_smile:

anyway, it’s certainly a good thing for AP to emit a “gps fake” if there is no gps, irrespective of STorM32

(have you seen my ardu git comment, it’s IMHO not thought out)

anyway the II, it seems to me that then it comes to gimbal functions we have very different point off views and I don’t see that we would come to a common view. But we don’t have to. So, that’s perfectly fine. :slight_smile: