common: add gimbal device joing angles extension

[julianoes]

For debugging and visualization purposes it would be nice to have the joint angles logged of a gimbal device. The quaterion is not enough for this purpose because the inverse kinematics to assume that attitude is not definied.

As requested by @cmic0.

[hamishwillee]

1. What is a joint angle? [unless this is extremely well understood in gimbal circles].
2. Is angle relative to something - i.e. a frame?
3. The units are rad/second but the name angle implies rad - seems inconsistent naming or unit.
4. This message is set at high rate right - is it worth the cost of these extra floats when this is not used?
5. Are there implications for systems that get this from a system that has not been updated and is sending 0.
6. Any other gimbal person you can suggest to review?
7. Are there other options - could it be a separate/optional message?

[julianoes]

1. It is custom to a gimbal. It depends on the physical construction.
2. It's just the joint relative to the other joint. Again, custom to each gimbal.
3. Thx, I'll fix that.
4. I think the rate is something that needs to be set depending on the bandwidth and requirements you have. If unused it should not be sent. I guess we could do 0 as invalid, so that it gets trimmed.
5. It's just feedback/debugging, so no.
6. @olliw42
7. I would rather not.

[hamishwillee]

OK, then let's see what @olliw42 says.

FWIW I really dislike this. Mixing general solutions and debugging in a single message might be sometimes necessary, but also to make it custom to a particular gimbal. Yuk.

[hamishwillee]

@auturgy Stakeholder review would be appreciated.

[julianoes]

Alright, I'm closing this and will create a debug message instead.

[julianoes]

New PR: #1708.

[jeremyzff]

I think that the gimbal joint angles DO belong in the normal status message. Here is why: Some gimbals won't know about their absolute attitude relative to earth frame, but do have their joint information. The joint angles are key information in computing the attitude of the gimbal. An example is having a lidar on the gimbal- It doesn't necessarily know which way its pointed, isn't trying to track the aircraft heading for corrections, but is just doing a basic stabilization. In order to to compute the angle of the laser, I'd need to take the aircraft attitude and use the joint angles to figure out the angle of the laser. This is just a simple example, but takeaway is that the angles are important.

Stepping back one step further, 3 joint angles aren't particularly future proof. If you have a 2 axis gimbal or a 5 axis gimbal, you have to figure out how to deal with that. It also requires the flight controller to have knowledge of the gimbal's configuration so it can properly do the kinematics from base to joint stage. I would consider a more generalized mechanism where the gimbal angles message (maybe make a separate message) contains a quaternion and translation from the base of the gimbal to the camera stage of the gimbal. This way, the gimbal is responsible for computing all the kinematics for itself, which it knows, and it reports a neutral value to PX4. If the gimbal has 4 stages, or is even a 10 link robotic arm, the quaternion and offset of the end effector is sufficient for PX4 to compute the end effector's orientation and position relative to its mount.

[hamishwillee]

@jeremyzff Discussion best move to #1708 (comment)

[julianoes]

@jeremyzff

Here is why: Some gimbals won't know about their absolute attitude relative to earth frame, but do have their joint information. The joint angles are key information in computing the attitude of the gimbal.

I think I disagree with this point. A gimbal gets the absolute angle of the frame/autopilot sent in the AUTOPILOT_STATE_FOR_GIMBAL_DEVICE and can compute its attitude based on that plus its joint angles. There is also the option for a gimbal not having to know the absolute yaw angle (relative to North) but to use yaw relative to the frame/autopilot. This can be selected using the GIMBAL_DEVICE_FLAGS_YAW_LOCK in GIMBAL_DEVICE_ATTITUDE_STATUS.flags.

Does that make sense?

And then for the debug message containing the join angles, it sounds like we should extend it to 5 angles rather than only 3? I'm aware that robotic arms have more than 3 joints but I have not come across this in a drone gimbal. Would be interesting to see one.

[hulk-ethan]

Your thought is that if this is a "debug" message, this is temporary and will eventually be replaced by something in the future that will exist inside of "GIMBAL_DEVICE_ATTITUDE_STATUS"?

As far as how the kinematics information gets sent, I agree with Jeremy that it would be more "complete" to have the framework for the aircraft to know exactly what the offset for the camera is (both rotationally and translationally, ideally in the future). I can imagine cases where we'll want to include kinematics offsets to our position data to better geotag the images.

For now, if we're going the route of a temporary/debug message, I suppose I don't really care: it can be implemented as simple joint angles or an additional quaternion for the gimbal base.

[julianoes]

Your thought is that if this is a "debug" message, this is temporary and will eventually be replaced by something in the future that will exist inside of "GIMBAL_DEVICE_ATTITUDE_STATUS"?

No it will stay a debug message. It's not temporary, just for debugging, from how I understand it.

As far as how the kinematics information gets sent, I agree with Jeremy that it would be more "complete" to have the framework for the aircraft to know exactly what the offset for the camera is (both rotationally and translationally, ideally in the future). I can imagine cases where we'll want to include kinematics offsets to our position data to better geotag the images.

Ok, so right now the rotational offsets of the camera are sent with GIMBAL_DEVICE_ATTITUDE_STATUS, however, the translational ones are not. Should they be added to GIMBAL_DEVICE_ATTITUDE_STATUS then? And is your gimbal able to estimate them?

or an additional quaternion for the gimbal base.

So we have the angle of the gimbal from teh GIMBAL_DEVICE_ATTITUDE_STATUS quaternion. Do we need an additional one? I'm sorry if I still don't understand.

[olliw42]

thx for pinging me, and sorry for being late

@hamishwillee
concerning what "joint angles" are, I think this is such an established term in robotics that there is little need to say anything about them, which is your (1) and (2)

@julianoes @jeremyzff @hulk-ethan

I think the problem is that you want to make a gimbal a robot
like needing joint angles, translational offsets (I'm not totally sure what you guys mean by that, I only can assume it's the distances as they would appear in e.g. Denavit Hartenberg matrices), 5 axis, and so on ...

while there might be cases where all this might be required/desired I think this clearly goes beyond the concept of a "gimbal" as something which is stabilizing the attitude and which can be pointed at something

that is, I would not be excited to see a status message - which indeed as @hamishwillee pointed out might be higher frequency - being flooded with lots of data which most of the time is not used nor needed. I frankly really have troubles with seeing that such data actually could be needed in practical applications ... at the end of the day there will be always a longer distance between where the gimbal is and where the action is so that offsets and other fancy really should be negligible ... knowing the gimbal's attitude and the position of the vehicle really should all you need to point your laser sufficiently accurately, do object tracking, and so on

if it's not pointing accurately enough then you have an issue with the gimbal and not with not knowing the joint angles...

btw, the gimbal base's attitude is available via the AUTOPILOT_STATE_FOR_GIMBAL_DEVICE message, as @julianoes has pointed out already

if you indeed think about something like a robot arm on a vehicle which can grab something, then I think you don't want to call it "gimbal" but indeed call it a robot arm ... and treat it as one, i.e. I think one then should rather think about introducing "ROBOT" messages
if you need the joint angles of your 5 axis thingy, then you likely also will need the joint velocities, and so on ...

so, my opinion, I don't think it's a good idea to throw all that at a gimbal

instead of a debug message for holding the gimbals joint angles, one maybe could think of an extended message, i.e. something named like

GIMBAL_DEVICE_STATUS_EXTENDED