Closed Epicrider closed 2 years ago
Will review tomorrow.
As written, the planner outputs are in the local CRS, because plotting them in WGS84 with Matplotlib (which is how I was verifying that the planner was working properly) produces nonsense since you can't really do addition and subtraction in WGS84.
I did write some helper methods: https://github.com/uci-uav-forge/uavf/blob/main/src/uavfpy/planner/mission.py#L535 to convert arrays of coordinates to/from the two CRS. I think it's useful to have the specific CRS transformer used to generate plans as a method of the mission
that was used to generate plans, that way if you need to subsequently alter plans that have been generated you can be sure that you are using the right CRS.
They are a convenience wrapper around https://github.com/uci-uav-forge/uavf/blob/main/src/uavfpy/planner/mission.py#L29 get_xformer_from_CRS_str
which produces a callable that takes the coordinates as floats. When creating the mission object, it's the callable that gets passed in.
I also added some constants https://github.com/uci-uav-forge/uavf/blob/main/src/uavfpy/planner/mission.py#L19 which cover testing and competition locations. It's better to use a CRS that is local to the area you are interested in, because precision errors can accumulate otherwise. For example, if I ran a mission using WGS84 coordinates that were located in Irvine, but used a CRS that was centered in Maryland, that would be less accurate than using a CRS centered in Irvine, because there's higher precision carried through the coordinate transformation.
After you create the plan, you will need to convert it back into WGS84 to be sent off to the flight computer.
By the way, if you add "#59" to your commit messages, it will link those commits to this issue. So the commits are linked in this issue and in each commit the issue is also linked. I usually just add it to the beginning i.e. git commit -m "#59 Changed CRS stuff"
or something like that.
I'm reviewing it, looking pretty good so far.
I'm going to make a couple changes:
I think it would be helpful to move some of the magic numbers in generate_waypoint
into an enum to keep things organized.
Going to close once I write documentation on how the script is used
Closed
see https://uci-uav-forge.github.io/uavf/generating-missions.html for how to use the script
Until we have a full Online Planner utilizing Mavros, we need an autopilot to fly missions autonomously. Until then we will utilize Mission Planner's Load Mission Functionality to read waypoints from a pre-made *.waypoints file.
https://mavlink.io/en/file_formats/
We can utilize this feature plus a re-wind feature as mentioned by @Herpderk to avoid obstacles manually when detected by our Interop code. It is also possible to load a mission while the drone is in the air, however this is more technical and will go in another issue.