Passing Waypoint for Position Control

[QRI-nashw]

So I am using the OSDK to pre-program a waypoint mission, and instead of using the mission manager, I would like to use the moveByPositionOffset to accomplish moving from point A to point B. I noticed in the most recent version of the flight_control_sample.cpp that there is a localOffsetFromGpsOffset, and I'm guessing this is somehow used to convert a Longitude/Latitude waypoint into usable parameters for moveByPositionOffset, but I'm not sure how. Can I get a little clarification on this?

Also, how exactly does one pass a GPS position to these functions?

Thanks!

[rohitsantdji]

The moveByPositionOffset function is primarily designed to take in a x,y,z offset to move by, referenced to your current position. The localOffsetFromGPSOffset function is currently only being used to convert telemetry data (which is in absolute GPS coordinates) to a local x,y,z offset. So the intended use case for the moveByPositionOffset is when your requirements for the motion are in terms of local x,y,z.

[QRI-nashw]

@rohitsantdji How local are we talking? Could the localOffsetFromGPSOffset theoretically be used to move the drone a few hundred meters? Or is there some sort of limiting factor that restricts the use of that function. I am trying to create an application that has the drone go from GPS coord A to GPS coord B without having to use the mission manager, is this possible?

[rohitsantdji]

It could be used for a few hundred meters - the accuracy will degrade as you go farther from your start point since this conversion does not take into account the curvature of the earth etc. But the degradation in accuracy won't be huge, maybe tens of cm over a few hundred meters.

Could you tell us the reason you are trying to avoid the missionManager? The moveByPositionOffset is meant as a piece of sample code, so you might have to do some tuning with the algorithm used in that function to make the control precise to your desired level.

[QRI-nashw]

The earth-curvature problem was what I was specifically worried about actually, so its good to hear that its not really a problem.

I'm currently working on a "cloud-enabled", click-and-go surveillance/anomaly detection system, and I think that for my purposes, it will be easier to use a simple moveToGpsPosition function instead of going through the missionManager, which to be honest with you, I've had considerable trouble understanding. The idea is that a user can select a few GPS locations online (for example: point A, B, and C), and have the drone fly to those waypoints sequentially. But if we wanted to, say, land at point B, turn off the motors, and use a sensor to get a reading before taking off and heading to point C, I think (at least for an intermediate level C++ programmer working on an initial prototype) the logic is easier to just have a list of sequential actions, and execute them one by one (move to point B > land > motors off > sensor on > etc.) instead of trying to get a hold on the missionManager and somehow interrupt the mission with a land + turn-off-motor + etc.

I'm definitely open to suggestions though! Thanks for all your quick responses so far @rohitsantdji , you've been very helpful!

[QRI-nashw]

@rohitsantdji Can I have a little more explanation on localOffsetFromGpsOffset? I'm wondering if I can use this function to produce parameters I can then pass to the moveByPositionOffset to accomplish moving from waypoint to waypoint. Is this possible? And what is an NED offset as noted in the Helper Functions code comments:

// Helper Functions

/*! Very simple calculation of local NED offset between two pairs of GPS
/coordinates.
    Accurate when distances are small.
!*/

[rohitsantdji]

NED = North-East-Down. Yes, you could pass two GPS points and get the x,y,z distance (not corrected for earth's curvature) between them through this function.

Regarding the MissionManager discussion - I would like to say that the MissionManager is built very much for such purposes. The design of the missionManager allows you to chain waypoint missions together, and after each waypoint mission you can have it configured to execute a landing step. If your use case involves landing at each waypoint, then maybe the missionManager is not really adding any advantage but if there are other, non-landing actions that you need to do at each waypoint (and landing actions at only some of the waypoints), the missionManager would be the best way to accomplish this. You can also trigger custom sensors or actions by writing your own callback function for handling mission events (such as waypoint reached) and using the setWaypointEventCallback API.

[QRI-nashw]

Ahh okay, thank you.

And to your point about the missionManager, I'm sure it is designed to do exactly what I'm trying to do, but the fact of the matter is that I just don't understand how it works. After going through dji_mission_manager.cpp and mission_sample.cpp, I can't find any particularly useful code comments or documentation on the DJI website that might help me to understand. I would love to use the missionManager, as I'm sure its probably more intuitive and simple than I'm perceiving it to be, but I haven't been able to figure it out. Any help would be awesome!