Enhancement: Gimbal Orientation/Mount Status Graphics

[olliw42]

I have seen several Enhancement request here, so I hope it's OK to put this one up here; since the recent rearrangements I'm still highly confused which communication channel is best for what.

This is in relation to Randy's latest video on the Antenna Tracker, http://diydrones.com/profiles/blogs/antennatracker-v1-0-on-navio2-with-bebop2, where both the flight vehicle's and antenna tracker's heading and current WP lines are shown in MP.

This made me thinking that it would be quite cool to have an analogous feature also for a gimbal attached to the flight vehicle, i.e. that in addition to flight vehicle's lines also a line for the current heading of the gimbal would be displayed. This here is intended to discuss how that could be achieved.

I didn't really understood how that worked for the antenna tracker, the wiki didn't yielded much, and it might be that the suggested gimbal thing is already supported by MP. If so I would be happy to get my lack of knowledge filled, and what from the gimbal's side would have to be done. Specifically, I could imagine that a MAV_MOUNT_STATUS message could do that, or that the gimbal needs to appear as an additional component or system and emit an ATTITUDE message.

Any ideas how that could be achieved with the current MP, or which additions would be appropriate, would be very much appreciated.

Thx, Olli

[meee1]

MP already has basic support for this. but is not very configurable at the moment. to enable it in MP you need to have a very specific param set.

MNT_STAB_TILT = 1 MNT_STAB_ROLL = 0 MNT_TYPE = 4

with these settings and valid attitude data from compid 67, it will show a point on the map of the centre of the gimbal directions.

where things get complicated is the yaw that is returned by the gimbal, vs the plane/copter yaw.

[olliw42]

oh, very cool, I have to try asap

does one need GPS for that to work?

is MNT_TYPE=4 a hardwired requirement by MP (and/or compid 67), or does it so-to-say just makes ArduPilot emitting some special messages which trigger MP to do that, e.g. the Attitude message you mentioned?

Would it be conceivable to "generalize" the concept a bit and also make use of a MAV_MOUNT_STATUS message. One probably could easily add a flag somewhere in MP which allows the user to set showing the mount, maybe in the Config/Tunning-Planner section.

The yaw thing I also realized. I think one either could extend the existing mav message(s) a bit by misusing a field to set a flag telling if its absolute or relative to the copter, Or again a MP flag ...

Thx, that's very cool.

[meee1]

the check is here to run the code https://github.com/ArduPilot/MissionPlanner/blob/master/GCSViews/FlightData.cs#L1273 then the sysid 67 check is here https://github.com/ArduPilot/MissionPlanner/blob/master/Utilities/GimbalPoint.cs#L141

there is a mount status check in there as well for non MNT_TYPE 4's which could work already.

the issue always come back to yaw, a lot of the code assumes that 0 yaw is the front of the uav

[olliw42]

the links were extremely useful, THX a lot so it seems that there is actually already EVERYTHING in place, including using the MOUNT_STATUS whenever appropriate, and I just failed to notice, fantastic work :)

I'm not totally sure how the if line in the first link is digested by C# (which I think is what you use), but it seems to me it's

( ContainsKey("MNT_STAB_PAN") && (MNT_STAB_TILT==1 && MNT_STAB_ROLL== 0 ) ) OR ( MNT_TYPE == 4 )

so that MNT_TYPE == 4 by itself would actually do the trick already

I'm a bit puzzled by the MAVlist[MainV2.comPort.sysidcurrent, 67] in the 2nd link. I would think that the SysID is that of the autopilot, i.e. 1, which would imply that only ATTITUDE messages with SysID=1/CompID=67 would be digested. This confuses me since the STorM32 doesn't support being a component, so I wonder how that ever could have worked or be tested. I might think about and suggest a more consistent conditioning, if you don't mind. Maybe it would be easier and more consistent to set a flag if MOUNT_STATUS messages are detected and/or if a system of GIMBAL type is present. I assume in the code you have all that info readily available, so that anything would be just a minor effort.

As regards yaw, I think it's then a non-issue, at least with the STorM32. It already emits a yaw relative to it's forward (whenever it is possible, i.e. with 2nd Imu enabled), and it's always easy to ensure that also in future. So, it's essentially only a thing of officially/colloquially defining the MOUNT_STATUS and ATTITUDE (of GIMBAL types) messages.

I could not get this thing to work on my test bench. I however also don't get the flight vehicle symbol, so there are obviously some additional conditions I need to fulfill, hopefully it's not GPS (as it would be in a cellar LOL). Will have to see.

Please allow me two, somewhat unrelated comments:

• I noticed that then the gimbal is set to SysID=71,CompID=67, that when MP has a lot troubles to connect (at least for me), while with SysID=1,CompID=67 it works always (I have a test code which allows that). I actually don't think it's necessarily a MP issue, I have found that for SysID=71,CompID=67 there is all sorts of "crap" emitted by the autopilot, e.g. a lot COMMAND_LONG_ACK messages, which seems to confuses things. I just wanted to mention.
• The system field (the one left to the CONNECT button below the COM fields) behaves a bit strange, and can be actually misleading. It seems to me that the issue is that it is not correctly updated when a connection is established, or a disconnect happens. E.g., after a connect I would expect it to show the correct system, however it can be blank, or show the previously selected/connected system! Also, on a disconnect it would make more sense to me if that field would go blank.

THX a lot again. Sorry for the long text. As it seems the ball is my playing field. :) cheers, Olli

[meee1]

as I wrote the code, I'm pretty sure the mount status assumes it is not a storm gimbal, and the autopilot is providing the mount status, and as the values are pull from the current connected vehicle. (ie gimbal 100% controlled from the uav, using ap_mount etc)

and as you suspect if it is a storm gimbal it assumes that the sysid is the same as the current target vehicle. ie uav is sysid 1, gimbal is sysid 1, but gimbal has compid as 67. I tested this some time ago, so things might have changed in your mavlink side.

so quick rundown is gimbal configured to sysid = same as uav, compid as 67, it must be outputting mavlink attitude, with yaw of 0 = forwards, roll as always stabalized at 0 degrees, pitch adjustable and mnt_type = 4.

the reason I don't use mount status is because the message is treated separately per sysid/compid pair. ie the uav could have a mount status as well as the gimbal, and there is no way to tie the fact that the gimbal is attached to the uav otherwise, this is what the same sysid is used. so one can identify that the gimbal is attached to the specific uav.

[olliw42]

I've checked my codes, and since v0.70, which was the first official release with MAVLink, released in 5.Apr.2015, I have a line which rejects any messages with SysID identical to the gimbal's SysID, effectively preventing its use as a component. It has not changed since. However, this only affects incoming messages, but not the emitted messages (heartbeat, attitude). So, what I think is going on is that your code works in as much as it shows the gimbal point correctly, but that it is NOT possible to e.g. control the camera orientation (which is what the mount thing is for). So it seems an either-or situation, either working gimbal point (gimbal SysID=1), or working mount (gimbal SysID<>1). Maybe that clarifies things.

Thx for the last comment. It's indeed a good argument.

I'm afraid however that there won't be a resolution of the either-or situation from my side. I have too many concerns with Mavlink, or it's concept in fact, which I consider deeply flawed in many ways, especially when it comes to components. That's not what I want to discuss here, just to state, as a kind of fact of affairs.

I considered it a bit weird that the MOUNT_TYPE=4 class doesn't emit a mount_status message, which could resolve things. I noted that in the "how to add a mavlink gimbal" memo there is no mentioning of mount_status and/or attitude or such.

Since all the above special case handling seems to be very specific to the STorM32, and not to a Mavlink gimbal in general, which MOUNT_TYPE=4 probably is supposed to be, I wonder if it couldn't be better to single out the presence of a STorM32 by the heartbeat's autopilot field; the STorM32 identifies itself as type=GIMBAL and autopilot=83 (supposed to be MAV_AUTOPILOT_STORM32). This wouldn't resolve the either-or issue, but might be a somewhat more apt identification procedure than via MOUNT_TYPE=4 and CompID=67.

Anyway, I am very please that a thing like a GimbalPoint is already existing, and I think I understand its working requirements quite well now. Thx for all that.

[olliw42]

sorry, pressed the wrong button LOL

[olliw42]

ok, in a test setup I have seen this GimbalPoint now. Cool :)

It seems to also take into account the tilt, at least it was changing its distance from the vehicle in my case, which I interpret such that the point tries to be where on the ground the gimbal is supposedly looking at (I think your 2nd link into the code supports that). I'm not sure if that is most convenient. Often one would not tilt the gimbal, or not inspect something on the ground. Maybe an additional heading line could be useful.

Anyway, great stuff :)

[olliw42]

I'd like to conclude that from my side with some final suggestions

• I think I would enhance the gimbal point by a blue line, which connects from the vehicle to the point. In case the point leaves the display, the blue line would remain and extend to the borders of the map.
• Identifying the STorM32 by MOUNT_TYPE=4 and CompID=67 is perfectly fine from my side. I guess I nevertheless would consider using a more "logical" strategy.
• I continue to have serious issues with connecting to MP when the STorM32 SysID is set to 71. I still think it's not an issue of MP per se, but I would take that as a clear indication that something is significantly wrong with the Mavlink routing stuff. A camera trigger issue recently turned out to be related to the recent incorporation of Mavlink2. I would speculate that's here too.
• The behavior of the MavSystem field next to the CONNECT button is highly confusing.

I like using MissionPlanner a lot, thanks for all your work over so many years. Cheers, Olli

[arBalasquide]

@olliw42

Hey, sorry to ping you on such an old issue but did you ever get around making a fork for having a blue line for the gimbal orientation?