Gimbal Control Crosswind Enhancement

[Daniel314159]

Issue details

I fly in a very windy part of the world. I would like the ability to rotate the yaw on the Storm32 gimbal using the pixhawk flight controller in such a way that the gimbal is oriented with the actual flight path of the aircraft instead of the aircraft's heading. For example see the attached photo. I would like the camera to be aligned with the black line, not the red line.

Usually when I am mapping with my plane the camera is pointed straight at the ground. If the camera could align with the actual flight path instead of the aircraft heading the image quality would be greatly improved.
_

Version

Not Applicable

Platform

[ ] All
[ ] AntennaTracker
[X] Copter
[X] Plane
[ ] Rover

Airframe type

All Airframes

Hardware type

pixhawk, All

Logs

Please provide a link to any relevant logs that show the issue

[LenSun]

Gimbal absolute yaw is unknown,while plane yaw is updated.As long as plane sends relative_angle cmds to gimbal, the camera would align with the black line.The relative_angle is the difference between plane yaw and black line angle in world.

[magicrub]

All that information is available to the gimbal, I think it's up to that gimbal to make the decision to point that way instead.

[Daniel314159]

The Storm32 Gimbal controller developer referred me here. I am looking at the code and it appears at least some of the gimbal mode information comes from the PIXHAWK. For example MAV_MOUNT_MODE_GPS_POINT. I am not an expert coder. So I may be mistaken.

[olliw42]

All that information is available to the gimbal,

I think that's in general not correct. It is certainly not correct for the STorM32 controller. The gimbal knows two things:
(1) it knows there the front of the vehicle is
(2) it knows the commands it got to point to somewhere else than to the front of the vehicle
It does not know about wind. And unless the gimbal would run its own complete AHRS (with gps, mag etc. pp) it can't, and IMHO it really doesn't make any sense for the gimbal to run it's own AHRS if it has one potentially much better next door (and I think you guys are saying that your AHRS is potentially much better, right ;)), and I think you wouldn't want it to do it, and if it's just because of weight.

I think LenSun is right, ArduPlane could simply send a correction command to the gimbal. I.e., this correction could be simply added to the orientation which is feed anyhow to the gimbal.

I in fact think that this would be a cool addition to AP's gimbal support. I'm actually surprised that it has never come up before, I mean, it's in some ways so obvious that one would want that.

[Daniel314159]

@rmackay9
olliw42 mentioned you where working on improving gimbal support. Just bringing this thread to your attention. You've probably already read it : )

[geofrancis]

An option for the gimbal to use gps track for orientating the gimbal would be good. The only time I think there could be an issue is flying into a headwind strong enough to push you backwards. It might then start looking at the tail.

[Daniel314159]

Agreed. Either your suggestion or mine would work. The only issue with orienting the gimbal with the gps track is when flying a survey grid the camera would abruptly turn at right (or beyond) angles to the plane. If you had a acute angle in the gps track you could end up with camera pointing sharply back. I have been slowly reviewing the code associated with gimbal control. Not sure If I dare touch anything at this point.

[geofrancis]

what about aligning the gimbal with the next waypoint? it could have a delay on it so that it doesnt point towards the next waypoint for say 5 seconds, that way its already started the turn before the gimbal moves limiting how far it has to turn.

[magicrub]

If it's just to look forward, gps coarse over ground is what you want. However, I'm not sure of what we want yet and why can't the gimbal do this?

[magicrub]

This is the line that would change... But hardcoding it to CoG doesn't seem right. Need a new param?

https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_Mount/AP_Mount_SToRM32.cpp#L77

[geofrancis]

i dont think this should be part of the storm library, it would be better making it so it could be used with regular servo gimbals also.

[Daniel314159]

i dont think this should be part of the storm library, it would be better making it so it could be used with regular servo gimbals also.<

Agreed. I don't think this feature would need to be storm specific. It would be great if all the supported gimbals could do it.

[magicrub]

agreed. Needs a param or mission item variable so we know where to point. The DO_MOUNT_CONTROL command, that is used by Storm32, has the ability to point to a way point.. such as the next waypoint (or a generated one projected 1km ahead if we wanted to).

[Daniel314159]

I like the ideas. Do_mount_control always points at something however. I would like gimbal to point straight down at all times. The gimbals already do that well. The second item is just changing the yaw orientation by any angle equal to the aircrafts true course - the aircrafts orientation.

The reason I am trying to do this is I am doing aerial mapping/photo stitching using Microsoft ICE. The pictures all need be aligned within a couple of degrees for the stitching using the ortho mosaic settings. I can rotate the photos using photo editing software but I lose definition and photo size. My camera setup is simple - just a camera taking a picture every five seconds while mounted in a gimbal.

If the gimbal could orient with the true direction of travel it would be usable even when the aircraft is in other modes like FWBA and Cruise Mode. The image below explains further. The image shows the photo foot print on the ground.

The biggest benefit this would provide is aerial mapping and crop analytics could be done entirely with free / open source software with less hardware cost than currently is typical.

I am a hobbyist programmer (I've been paid for a machine programming project once) so feel free to straighten me out. The information on the aircraft's direction of travel, airspeed, and position are not available to the gimbal controller. All the gimbal gets is a series of angles to point in from the pixhawk. What I am looking for is a yaw_correction. The rest could be controlled from my rc_tx or is already supported.

@olliw42 knows a lot more about gimbals than I do. Maybe he has some input on the best way to handle this.

[olliw42]

I shared already what I think is the "best way" to handle this

I think LenSun is right, ArduPlane could simply send a correction command to the gimbal. I.e., this correction could be simply added to the orientation which is feed anyhow to the gimbal.

[tridge]

changing to use CoG does make sense for planes

[tridge]

what mount mode are you using? Either in MNT_DEFLT_MODE or controlled from mavlink?

[tridge]

we're thinking a MNT_YAW_BEHAVE parameter, which would be 0 for current behaviour, 1 to switch based on fly-fwd. Default would be 1.

[Daniel314159]

I have used both MNT_DEFLT_MODE and controlled from mavlink. The MNT_YAW_BEHAVE parameter looks like a good solution. I will look this over a bit more tomorrow night. Is there a particular mount mode I should be using?

[Daniel314159]

Are you waiting for some feedback from me? I am new to github.

[Naterater]

Really would have liked to see this in the 3.9 releases!

[Daniel314159]

Yes it would have been nice. I am not a good enough coder to implement it myself without a lot of work understanding the code. I am an accountant who codes as a hobby - hopefully next spring I can get into the UAV and automation market more.

[Naterater]

Why doesn't MNT_STAB_PAN: Stabilize mount pan/yaw angle do this automatically?

[tortfeaser]

I can see another use case for this functionality. Obstacle avoidance now requires a 360deg LIDAR ($$$) if a more cost effective single direction LIDAR can't be pointed in the direction of travel. It would be great to be able to have a simple sensor mounted on a servo gimbal that is commanded to point in the direction of travel, and so if some obstacle got in the way of a programmed path, it could be sensed and avoided.

So this functionality would be useful for Copter as well as Plane.