Interface for proper footstep plan stitching

[Alexander Stumpf]

We,ve already made some experiments using IHMC walk and our (endless) footstep generator. Hereby it's not very clear to us how your interface is intended to append (stitch) new steps cleanly to the current execution pipeline (see ticket #10).

Furthermore there is no clear feedback about which step is currently executed and which step (index) may be still changed. The last one is needed for any kind of replanning. The footstepIndex (FootstepStatusMessage.msg) will be resetted to count from zero every time we send an updated step plan.

Thus, I propose to extend your inteface to support plan stitching and better feedbacks (if not already implemented). Can you please provide us a tutorial how stitching should work cleanly?

[DouglasS]

@stumpf The current implementation doesn't support stitching/concatenation of footsteps, nor does it support replacing a footstep in the existing list. The way the current implementation is set up, if you were to send a "new" list of footsteps to the robot while it is in the middle of processing an existing one, it simply drops the current list and switches to the new one upon completion of whatever step is in progress. This will be problematic for you if you're attempting to concatenate as the footsteps are in world frame.

As such, we don't currently have a mechanism to track which footstep is currently being executed; our current strategy is maintaining a FIFO structure that gets popped every time we receive a "footstep completed" notice.

We've added this to our triage list for new features and will be discussing it as there are some people internal to the team that are also interested in these features. In the meantime, the workaround is to hold on to the state of the list of steps on your end and do the editing on the whole list, then send the whole list over. Thanks for the feedback and we'll let you know as soon as we make a decision on this.