I think it might make sense to move the logic responsible for generating waypoints to Unity for the final game system, since collision avoidance will eventually also be implemented in Unity.
With the waypoint mapping done in ROS, the information flow is
Control input (Windows) --> Waypoint generation (Linux) --> Checking waypoints for potential collisions, modifying waypoints (Windows) --> Quadcopter navigation to modified waypoint (Linux).
If waypoints are generated in Unity we don't need so much back-and-forth information flow:
Control input (Windows) --> Waypoint generation (Windows) --> Checking waypoints for potential collisions, modifying waypoints (Windows) --> Quadcopter navigation to modified waypoint (Linux).
However, the waypoint mapping in ROS makes use of the tf tool, so that we don't have to calculate transformations from quadcopter frame of reference to local frame "by hand". The transformation is probably not complicated though, and maybe Unity has a similar utility.
g-simmons
commented
5 years ago
I think it might make sense to move the logic responsible for generating waypoints to Unity for the final game system, since collision avoidance will eventually also be implemented in Unity.
With the waypoint mapping done in ROS, the information flow is
Control input (Windows) --> Waypoint generation (Linux) --> Checking waypoints for potential collisions, modifying waypoints (Windows) --> Quadcopter navigation to modified waypoint (Linux).
If waypoints are generated in Unity we don't need so much back-and-forth information flow:
Control input (Windows) --> Waypoint generation (Windows) --> Checking waypoints for potential collisions, modifying waypoints (Windows) --> Quadcopter navigation to modified waypoint (Linux).
However, the waypoint mapping in ROS makes use of the tf tool, so that we don't have to calculate transformations from quadcopter frame of reference to local frame "by hand". The transformation is probably not complicated though, and maybe Unity has a similar utility.