RTH to Drone Position vs Takeoff Grid Position

[esnelling]

If user inadvertently changes drone object positions, the RTH feature returns drones to the moved drone object position. This condition is normally masked as the drone objects are tied to the formations all the way until RTH is selected at end of show. Please consider that RTH to the takeoff grid might be more resilient to this user error. Just a suggestion; there may be good reasons it's done the way it is currently.

[ntamas]

There are no particular reasons; it was easier to code things this way, but we can change it. The only problem right now is that the takeoff grid is not marked in any special way in the storyboard, it just "happens to be" the first formation. So, instead of looking at the takeoff grid explicitly, what we would need to do is to look at the first formation, find which marker the drone is constrained to in that formation, and RTH above that point instead. Would that be sufficient?

(Needs to be decided what to do if the drone is not associated to any of the markers in the first formation. It is a remote possibility, but not entirely unlikely so it needs to be handled somehow).

[esnelling]

In my mind, the chances of one altering the "Takeoff Grid" name is less likely than inadvertently moving the drone objects. I have actually done this myself many times. So I'd think you could just grab those xy positions and put the RTH formation above that. I can't think of a scenario where the Takeoff Grid number of objects will be different than the drone objects at end of show.

This is minor problem which is easily fixed by ensuring one does not inadvertently move their drone object world positions. Thanks for considering. On second thought, a much better suggestion would be to add this as a tip in the user manual if not already there.

[esnelling]

I would like the option to have drones return to the "Takeoff" formation when using slotted (layered) takeoffs. So when selecting RTH, I need the drones to return to their layered heights versus a flat grid. Even when I set the initial drone positions to their associated layer heights, this still doesn't work for some reason.

Since the existing function seems to work for many, perhaps there could be an option added in the RTH window such as "Return to Takeoff Formation". I would like this to work with Smart RTH too.

Thanks for consideration.

[ntamas]

So when selecting RTH, I need the drones to return to their layered heights versus a flat grid.

Right now the RTH algorithm explicitly returns to Z=0. May I ask what's the use-case for returning to a possible layered takeoff formation instead of simply landing the drones as fast as possible?

[esnelling]

In drone fleets established prior to SkyBrush Live being an option, the other software returns the drone to the last frame of the Blender show at several meters above ground. From there the drones are issues either a "LAND" or "RTH" command. Since the initial grid for slotted takeoff is reduced, returning them all to Z=0 results in an airborne grid which is too close.

Option 1: Append the "Takeoff" formation (layered) and compute a normal transition to it. But absolutely requires "LAND" for sure because "RTH" will cause collisions. In my configuration, I can add a successively longer "LAND" delay for each layer to add further safety. But it becomes very impractical to do this since there is a certainty that many drones will have shifted to a different layer.

Option 2: Returning the drones to their original start positions in the "Takeoff" formation has two advantages for my configuration. It allows me to easily set an increasing landing delay time for higher layers to add safety. And being able to use RTH for the final landing allows me to set the drones down very precisely when takeoff is in close proximity to obstructions or water.

BTW, you are a genius in all this implementation. I have written several scripting methods to try and accomplish this but none have been satisfactory. The closest one can frequently take twice as long as necessary and very much a brute force, non elegant method.

[ntamas]

The current implementation makes several assumptions about the final positions of the drones all being at the Z=0 level and that the initial positions are all well above Z=0, so returning to positions with arbitrary Z coordinates is not an option. Skybrush is opinionated in the sense that it assumes that all trajectories are planned from takeoff to landing and they do not start or end in arbitrary points in the air, and we believe that from the point of view of safety this is the right thing to do. The fact that you can design shows in the Blender plugin for other software where this assumption is violated is a happy co-incidence, but this is not endorsed by us by any means. Unfortunately, putting active effort into supporting flight configurations that are peculiar to other drone swarm control software but not ours takes considerable effort from our side and brings in all the safety concerns mentioned above, while bringing only marginal gains from the business perspective.

(Sidenote: in future versions of Skybrush, we have plans to support "partial" shows where the show file contains the trajectories only from the first formation to the last formation and where a layered takeoff and landing sequence is generated dynamically, within Skybrush Live (or the server), without any additional input from the operator apart from the current positions of the drones before takeoff and the relative placement of the show center. This is seemingly different, but in practice it still holds that all trajectories that are uploaded to the drones start from the ground and end on the ground, not in mid-air).

Going back to the original problem presented here, I believe that one workaround you could use is as follows. Pretend that Z=0 in Blender's coordinate system corresponds to an altitude of, say, 5m. Design the show accordingly, starting the drones from Z=0 in Blender, use a slow (possibly layered) takeoff and trust that other drone control software to command the drones to take off at the appropriate times to reach the designated positions in the trajectories fast enough. Then, at the end of the show, command the drones to land using smart RTL in Blender, and when exporting the trajectories to the other drone control software with your own scripts (I assume you use your own scripts), cut the trajectory of each individual drone at the point where it reaches Z=0 at the end. The length of each trajectory will be different as each drone reaches Z=0 at a different time, but when the drone reaches the end of its own trajectory (reaching Z=0 in Blender coordinates, which corresponds to an altitude of 5m), its control routine will switch to LAND immediately and the drone will continue moving downwards, so they will not end up in a hovering grid configuration in the air.

[esnelling]

It is a happy coincidence indeed! I share in your opinion and prefer the drones to be in guided mode ASAP. Thank you for the thoughtful response. I can understand that Smart RTH to a specific layered landing formation is challenging. I have programmed several methods for this and my best result so far takes about twice as long. The results are sometimes funny. Thank you for considering and I will close issue if that's OK.

[AugaZauga]

Plus one for this request **

If we were able to set the Smart RTH to go back to the takeoff position, or even its own position/set of empties (Which would basically adjusted to match the takeoff position), my current issues would be resolved. I've tried adjusting the Formation empties within the Smart RTH collection to no avail.

If there was an option to return to the takeoff formation then we could continue programming these staggered shows efficiently. Thank you!