Plane: Survey friendly crab algorithm

[MrMap]

For ortho survey missions it would be beneficial to have the navigation controller make crab adjustments using flat turns (provided that the model has yaw control surfaces) over roll (banking) turns. To keep the camera pointing downwards even during variable sidewind vectors. This would probably increase the photo quality yield during turbulent / side wind survey missions.

It would be elegant if the flat turn preference cold be activated by the new camera trigger feature, so to use flat turns during photo aquisition part of the mission, while using normal turn coordination during other flight phases (start, transport legs, approach & landing).

Tom

[meee1]

have you considered a roll stabilised gimbal? as this will work in gusts and other turbulence.

[MrMap]

Yes I have considered a roll stabilized gimbal and it will obviously work (better) in many situations. In my current X8 mapping plane I had originally planned a gimbal but later decided against it in order to have the camera installation, and overall design, simpler and more resiliant to field use beatings.

Looking at the turn-key survey drone market, I think all I know about, except the Pteryx, went for fixed camera installation for the same reasons. And the pteryx is more or less replaced by a new gen. form the same makers, with fixed camera. But again, techically I agree - roll gimbal is certainly the default solution to the problem.

[bbasso]

Tom, I think assuming something about your aircraft dynamics, like independent yaw control, is not that great, because then your mapping solution becomes airframe-specific. I use delta wings, for example, which of course can not yaw independently of rolling and pitching.

Gimbals are nice, especially for windy conditions, but they add complexity and cost. Better to just plan slightly longer missions that over run the edges of the area you're interested in mapping. I've also been thinking about adding something to the camera triggering that inhibits the trigger beyond a certain roll angle, as an option. This would make it easier on the stitching software.

Brandon

On Sun, Nov 3, 2013 at 4:00 AM, MrMap notifications@github.com wrote:

Yes I have considered a roll stabilized gimbal and it will obviously work (better) in many situations. In my current X8 mapping plane I had originally planned a gimbal but later decided against it in order to have the camera installation, and overall design, simpler and more resiliant to field use beatings.

Looking at the turn-key survey drone market, I think all I know about, except the Pteryx, went for fixed camera installation for the same reasons. And the pteryx is more or less replaced by a new gen. form the same makers, with fixed camera. But again, techically I agree - roll gimbal is certainly the default solution to the problem.

— Reply to this email directly or view it on GitHubhttps://github.com/diydrones/ardupilot/issues/651#issuecomment-27643303 .

Brandon Basso, PhD :: Senior Research and Development Engineer :: 3D Robotics :: Berkeley, CA

[MrMap]

Brandon, I agree such a solution would only be usable for airframes with yaw control surfaces. Point being it would introduce an increase in rudder usage for heading adjustment while still keeping wings reasonably level. Intended for planes without roll gimbal. But if this feature is to be implemented it would of course be user selectable. So one could choose whether to to use the "flat turn" option during mapping mission or not. And like you point out, if the airframe has no rudder surfaces it would obviously be out of question for that particular airframe. In my current Project I am working on a X8 modified to have rudders.

Frankly, I don´t know that this flat turn feature would be truly useful, but I imagine it might. I Think the only way to know for sure is to try it and I am willing to do so if the feature is created.

Tom

[bbasso]

Trying is the best way to find out!

Also worth considering--many stitching packages are not very robust to low overlap or irregular overlap, which may occur at the edges when making a pure-yaw turn.

-Brandon

On Mon, Nov 4, 2013 at 10:51 AM, MrMap notifications@github.com wrote:

Brandon, I agree such a solution would only be usable for airframes with yaw control surfaces. Point being it would introduce an increase in rudder usage for heading adjustment while still keeping wings reasonably level. Intended for planes without roll gimbal. But if this feature is to be implemented it would of course be user selectable. So one could choose whether to to use the "flat turn" option during mapping mission or not. And like you point out, if the airframe has no rudder surfaces it would obviously be out of question for that particular airframe. In my current Project I am working on a X8 modified to have rudders.

Frankly, I don´t know that this flat turn feature would be truly useful, but I imagine it might. I Think the only way to know for sure is to try it and I am willing to do so if the feature is created.

Tom

— Reply to this email directly or view it on GitHubhttps://github.com/diydrones/ardupilot/issues/651#issuecomment-27711574 .

Brandon Basso, PhD :: Senior Research and Development Engineer :: 3D Robotics :: Berkeley, CA

[AndKe]

in my experience, it's better to disable camera shutter during turns. With strong sidewind, rudder provides too sluggish/slow/small correction anyway to keep level. And the rudder-only turns get very big.

[MrMap]

AndKe, maybe you are right, maybe my idea works best in theory, less in reality. But I want to clarify that my suggestion addresses the "little" but frequent course correction turns that the plane makes during the straight legs in gusty weather, not the 180 degree turns between the survey legs.

But what about this idea: A feature that strives to release the camera trigger during a moment of low roll rate, to avoid blurred photos (during light conditions that require longer shutter speed). Lets say the trigger distance control is set up for 40 meter interval. And just at the trigger point the plane is hit by significant gust/turbulence resulting in firm roll rate correction that would result in a blurry photo. Then, 0,2 second (maybe 4 m) later roll rate is low and THEN the trigger is released. This would probably work best if the flight controller could calculate simpe statistics on roll rate usage to identify what should be considered "to high" roll rate vs "suitable" roll rate. The user would have to enter a parameter setting the maximum acceptable trigger delay. Admitted, a simpler solution would be to not fly in turbulent condition and/or use a camera stabilizing gimbal. But in real life many camera ships does not have a gimbal and flying opportunity might be a windy day. Jeez, this is acutally another feature... but related.

Anyway, I am going to suggest a feature (related) in Mission Planner survey pattern creater that does inhibit camera trigger during the turns between survey legs. As it works now the mission created contains one DO_SET_CAM_TRIGG_DIST (enabeling trigger) in the beginning of the survey pattern and one after the pattern is completed (disabeling trigger). During the turns a lot of junk photos are triggered.

[AndKe]

The last idea of yours is another feature request, and let me share my 5c on that too :) postponing a trigger in case of accelerations does seem like fine method. -but most cameras use at least 100ms before actually shooting - and if using IR triggers, additional delay is added. Needless to say, it's not foolproof. Delaying a picture would reduce you calculated overlap - which in turn reduces chances for having perfect data for the area anyway.

[bbasso]

Yes, I dont think we should be adding delay into the equation. We should more works towards zero delay between camera trigger events and time stamping of images in logs.

I can see some utility in inhibiting trigger events based on a roll or pitch. Maybe a RELAY_INH_RLL_LIM=xdeg sort of thing. Most stitching software can deal with pictures at an angle, especially if the angle is know, though, so I don't see it solving a huge problem, unless those images are somehow messing up the stitching process in your application.

[MrMap]

Hey - you are right. And now even I don´t believe in my own suggestion in this feature request - using only rudder for course corrections. I think that those gusty days the turbulence induced roll disturbances are probably a bigger source of blurred images than the needed course corrections. Which indicates that the feature requested would not make a big improvement.

I don´t mind closing this issue.