Path Planning Microservice TRAJECTORY_REPRESENTATION_WAYPOINTS

[flybrianfly]

In the path planning microservice TRAJECTORY_REPRESENTATION_WAYPOINTS message, there is an array of five uint16_t for MAV_CMD. How should the MAV_CMD be encoded? I'm familiar with MAV_CMD from the mission protocol microservice and the command protocol microservice, but I'm not seeing how the array of five uint16_t should be used to encode the MAV_CMD for the path planning microservice.

For mission protocol and command protocol, the MAV_CMD is a single uint16_t, but I can see the benefit of sending additional parameters, since the TRAJECTORY_REPRESENTATION_WAYPOINTS message lacks the param1 - param4 that MISSION_ITEM_INT messages have; however, the extra parameters in those messages are floats, not uint16_t, so I'm not sure how to encode the MAV_CMD piece.

[flybrianfly]

To add on to this slightly, what if my path planner would like to command the UAV to loiter to altitude or change speed, how would that be sent via the path planning microservice?

[hamishwillee]

HI @flybrianfly ,

This is the command ID of the MAV_CMD - that's the id that get's encoded in COMMAND_INT.command. I've updated common.xml to make that clear.

what if my path planner would like to command the UAV to loiter to altitude or change speed, how would that be sent via the path planning microservice?

That depends on your flight stack - there's a lot of potential for variation. But if you're using PX4 there is a lot more information here: https://docs.px4.io/master/en/computer_vision/path_planning_interface.html#px4-waypoint-interface

My understanding is that that PX4 would send out the message with the setpoint info from https://mavlink.io/en/messages/common.html#MAV_CMD_NAV_LOITER_TO_ALT and it's id "31" in the point0 and point1. The returned message from the companion just puts NaN into the field for the command.

Make sense?

[flybrianfly]

Makes sense, thanks!

[flybrianfly]

Apologies for re-opening this, but on a closer look:

1. I don't see how a companion computer would send PX4 a loiter to altitude command. From this documentation (https://docs.px4.io/master/en/computer_vision/path_planning_interface.html#px4-waypoint-interface), the only setpoint information commanded is vehicle position and velocity.

I'm considering a use case where the difference between the vehicle's current altitude and commanded altitude would require a descent rate exceeding the vehicle's capabilities. I suppose the options are to: (1) have the companion computer include a loiter command, or (2) have the companion computer send the command with no knowledge of the aircraft performance, the autopilot would then need to either insert a loiter or reject the guidance from the companion computer. I think it would be beneficial for the companion computer to be able to send the full-suite of MISSION ITEMS.

2. I'd like to have an API between UAS components that doesn't leave anything open to interpretation; it's the only way that we will improve interoperability between manufacturers as an industry.

[hamishwillee]

@flybrianfly My interpretation is that the companion never ever sends commands - it sends setpoints as discussed in https://docs.px4.io/master/en/computer_vision/path_planning_interface.html#companion-waypoint-interface

So to summarise,

• the TRAJECTORY_REPRESENTATION_WAYPOINTS is sent out by the autopilot with the current setpoint it expects to go to, the current waypoint and the next waypoint.
• The companion sends back TRAJECTORY_REPRESENTATION_WAYPOINTS with a setpoint.
  • If the planner does not know how to plan for the current command or understand the current intent (e.g. mission, or landing or whatever) then it just mirrors back the setpoint it got from the vehicle. That will be achievable of course since the autopilot planned it.
  • If the planner does know about the command/context then it does planning according to its own algorithm and sends back an appropriate setpoint for where it would prefer the vehicle to move.

The vehicle will then attempt to reach the setpoint. If it can't achieve the setpoint it just won't. It will however get new setpoints and attempt to follow those. I suspect this behaviour might not be utterly predictable, but then neither are the obstacles being avoided.

Upshot is that the interface doesn't know or care about whether the vehicle can meet the requirements. Probably a planner could do better if it has this information but we don't expose more than the vehicle type through MAVLink. I'm also not sure that it would be through this interface - there is a separation of concerns.

Thoughts? What would the planner want to know to do a better job?

[flybrianfly]

If the path planner knows the maximum ascent and descent angles, then it can ensure that the vehicle will be able to follow the vertical path guidance. This has been useful, especially for fixed wing vehicles, when trying to fly autonomous approaches to landing when the path planner was engaged with the aircraft too high and too close to be able to follow the glideslope. It can add loitering ascents / descents as necessary.

Additionally, if the airspeed and maximum bank angle are known, the path planner can take into account the vehicle turn radius when planning routes around obstacles.

[hamishwillee]

1. The trajectory API and PX4 planners were designed together to implement obstacle avoidance on multicopters (and later safe landing). So I would not be at all surprised if the needs of fixed wing vehicles have not been thought through.
2. There is no API to generically get that information - a GCS that wanted that information would need to know about the specific vehicle and query that using parameters.
3. It seems reasonable that you might want a separate standard message to get this information. Probably it would be a separate message and contain other useful information about a vehicle. If only because you would only need this once - the information would not change for a vehicle.

Let me see if I can get some more expertise involve in this. If not, might you attend the mavlink call next week to discuss? https://mavlink.io/en/about/support.html#schedule

[flybrianfly]

There is no API to generically get that information - a GCS that wanted that information would need to know about the specific vehicle and query that using parameters.

It seems reasonable that you might want a separate standard message to get this information. Probably it would be a separate message and contain other useful information about a vehicle. If only because you would only need this once - the information would not change for a vehicle.

I currently use a separate interface for configuration, but I can see how this would be useful to integrate into MAV Link. You're correct, you may want to have more information, especially if we consider VTOLs that may have transition zones from fixed-wing to vertical flight, etc. This could be a large message, since it is only needed once.

One thing that we're considering for future work is looking at whether having a full Flight Dynamics Model (FDM) available provides enough additional information to a path planner that it's worth the extra complexity in configuration. For example, we are currently using just a single value for setting maximum climb angle, but in reality this would depend on aircraft velocity and vehicle configuration. A full FDM on the path planner would enable more complex commands and higher accuracy at the cost of a much more complex initial configuration. I'm not sure that the benefits outweigh the cost of that complexity.

Back to the original issue, I think in the short term, having the ability for the path planner to issue standard MISSION ITEMS to the autopilot would go a long ways to improving the interface. The current MISSION ITEMS cover any maneuver that a path planner may want to command and enable the path planner to autonomously handle more complex mission scenarios than the current setpoint approach.

If not, might you attend the mavlink call next week to discuss?

Unfortunately, that's 3am local time for me, which is difficult to attend.

[hamishwillee]

The current MISSION ITEMS cover any maneuver that a path planner may want to command and enable the path planner to autonomously handle more complex mission scenarios than the current setpoint approach.

I so completely disagree :-0.

• This approach is actually the "old" way of managing dynamic missions - you have a mission, you spot that you want to change it for whatever reason, so you upload a new mission that has new points. It's a bit crap because the autopilot always finishes the last point it has buffered before doing the new waypoint, but it works and you could do this now if you really needed this.
• The setpoint interface provides the finest-possible-grained control over the vehicle - you are saying exactly where and how you want the vehicle to move. Sending a mission item is far more limited - you only have what the mission interface allows.
• I understand that it is "easy" - rather than plotting a precise path you simply command a new target. But it isn't as flexible.

[flybrianfly]

I so completely disagree :-0.

This approach is actually the "old" way of managing dynamic missions - you have a mission, you spot that you want to change it for whatever reason, so you upload a new mission that has new points. It's a bit crap because the autopilot always finishes the last point it has buffered before doing the new waypoint, but it works and you could do this now if you really needed this.

The setpoint interface provides the finest-possible-grained control over the vehicle - you are saying exactly where and how you want the vehicle to move. Sending a mission item is far more limited - you only have what the mission interface allows.

I understand that it is "easy" - rather than plotting a precise path you simply command a new target. But it isn't as flexible.

Ok, I see where you're coming from with this and can get onboard with using the setpoints. I guess I'm just trying to figure out a way to be expressive enough with setpoints that there is no miscommunication between the path planning computer and the underlying autopilot. Primarily, this is concerned with trying to command a loiter (either indefinitely, until a specified time, or until a specified altitude), but I could also see it extending to trying to provide more information - i.e. that a setpoint is part of a landing sequence, which may trigger configuration changes like lowering flaps or transitioning to vertical flight modes.

[hamishwillee]

@flybrianfly IMO commanding a loiter is something you would have to plan out yourself. The underlying mission is going to sit and wait until you do something that meets the requirement of going to the next waypoint.

The companion knows what the flight controller wants to do - i.e. it is going somewhere, landing, etc. so it has some context. However you might be right - I am not sure that if you were landing the flight stack would know that it should deploy the landing gear etc and I doubt the companion would be able to know about this with the current data exported.

Interestingly in offboard mode on PX4 these are taken care of since you can specify the type of a setpoint (this is a completely different model).

Let me see if I can find out more information.

[flybrianfly]

I'm circling back to this and Offboard mode seems really interesting. @hamishwillee, do you have any insight into when Offboard mode should be used vs path planning interface? They seem to be accomplishing the same end-goal and offboard mode seems to offer more flexibility. Understand that some of this may be historical, but as the developer of a newer flight stack, trying to figure out which services should be supported. Thanks!

[hamishwillee]

@flybrianfly Perhaps :-) YOu might get a better answer in the PX4 #computer-vision channel though.

The offboard mode has been around forever and is supported on many flight stacks as the way for a companion computer to precisely control vehicle movement - typically by providing position or velocity setpoints. It allows very precise control over movement by a companion computer.

However for the purpose of trajectory planning the problem is that it has zero understanding of what the vehicle is trying to do - you're handing over full control to the companion computer. That's mostly OK if the companion computer knows how to execute everything in a mission itself and you're just using your vehicle as a dumb platform. No one does this "in general" because you'd have to write something to convert missions to setpoints on your companion - possible and pretty cool, but not trivial. Further, some things might not be possible to implement in a companion computer - for example you might have a mission with a command to control a gripper - but if that command isn't supported on the flight stack in offboard mode, you can't use it.

By contrast, the trajectory interface provides an intent to the companion computer. That means if you're using trajectory planning in a mission you're getting the full benefit of the flight stack to execute your mission, with the companion computer providing setpoints as needed. The main use case being obstacle avoidance, where you only change the setpoints back to the vehicle if you see an obstacle in the planned path. You still get all the mission and existing integration with the ground station, etc.

I hope that helps! The approach was developed initially for PX4 obstacle avoidance, which is why I suggest asking on the PX4 slack channel.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.