David von Wrangel
David von Wrangel
A `.Clone()` function could be a great addition as well.
It would be great to extend the API of `GcsTrajectoryOptimization`. I will reply to each point separately. **Solving the convex restriction**: Providing `subgraph::get_vertices()`, `subgraph::get_edges()`, `subgraph::get_vertices()` and some refactoring with the...
**Adding/removing vertices**: Do you end up adding or removing a single vertex or the whole `Subgraph`/`EdgesBetweenSubgraphs`? We can definitely make the underlying GCS problem mutable, but it would be convenient...
**Naming the vertices**: How about changing the constructor of `Subgraph` to take a map of names to ConvexSet? An overload in AddRegions could generate some standard naming if only a...
In #20895, we addressed the getters for the subgraph vertices and solving the convex restriction. There is also a getter to the underlying GCS. The following remains: - A getter...
Interesting. AddEdges makes use of the from/target subgraph by using their order, alternatively one could provide a list of vertex indices similar to AddRegions like so: `AddEdges(from_subgraph, to_subgraph, const std::vector&...
In #20980, we found that exposing the edges associated to Subgraph/EdgesBetweenSubgraph doesn't add much benefit and only complexity, hence we are not adding the API for now.
Removing subgraphs and associated edges from GcsTrajOpt is now supported with #21006.
I think I addressed @sadraddini requests. Although he asked for a way in AddEdges to not check for intersections and manual addition, which should be a separate issue.
I ran into this problem a few times. Most hardware I have seen wants joint torques. However, in simulation I would love to see a setup that includes dc motor...