v4hn
5d9a9c22e4
invert 1:n relationship between InterfaceState and SubTrajectory
...
Starting with the Move Subtask, a single InterfaceState might have
multiple trajectories associated.
On the other hand, a graph structure of nodes is arbitrary difficult to handle,
debug and even specify. Because all examples considered up to now are
linear, I decided to stay with a linear ordering for now.
This should also allow much cleaner visualizations.
2017-03-06 20:47:56 +01:00
v4hn
a9c9a61710
add stub for pair iteration
...
This is not too hard, but takes a bit of time to get right,
so I'll add a stub for the moment.
2017-03-06 19:34:11 +01:00
v4hn
07b1a72030
add planning pipeline to task and subtasks
...
This allows to plan in the subtasks without ROS communication
2017-03-05 13:06:16 +01:00
v4hn
70145aae29
draft implementation of cartesian_position_motion - one way only for the moment
2017-03-04 00:08:52 +01:00
v4hn
30961436f1
subtask: add has* functions to facilitate canCompute
2017-03-02 19:35:31 +01:00
v4hn
c77d9106a6
introduce more interfaces / Gripper forward planning now works
2017-03-01 15:19:30 +01:00
v4hn
039f1e6896
Task now holds a PlanningScene
...
instead of just a RobotModel.
All generating subtasks need the scene,
so avoid every single one of them asking for it.
2017-02-28 16:47:09 +01:00
v4hn
0e5d39a94d
introduce a number of interfaces as loose ends
2017-02-28 15:27:05 +01:00
v4hn
bd67649fd2
first sketch of the graph design
...
+ skeleton of a first node "current_state"
+ vision of a test application
2017-02-28 11:29:38 +01:00