Using fallbacks efficiently

[joseph-moore-CO]

Hi all, I'm looking for suggestions on how to use fallback containers more efficiently when planning.

Part of my planning pipeline looks like:

• Generate IK solutions (typically around 8)
• Fallback
• • MoveTo (cartesian planner)
• • MoveTo (joint planner)
• Subsequent stages ...

The current behaviour of this is that for each of the IK solutions it will first try the cartesian planner, and if that fails try the joint planner. However, the joint space planner is very time intensive so I would prefer that if any of the IK solutions pass the cartesian planner stage, then we should not bother to run the joint planner at all.

Functionally, this might look like the fallback working through all its jobs (IK solutions) before deciding whether to move on to the next child stage. i.e. generate IK solutions, try the cartesian planner on all the IK solutions, if all of those stages fail, try the joint planner on all the IK solutions.

It feels like there probably is a way of wrapping up parallel containers to perform this operation, but I can't quite see it!

[rhaschke]

Interesting problem. I don't think, this can be easily achieved with current containers. The implementation of the Fallback container(s) consider each incoming job independently. Usually, this is desired behavior as there might be a large number of incoming jobs, which all would need to be processed before the next child stage is considered on those jobs that failed before.
However, this could be easily implemented using "busy" variants of the FallbacksPrivate containers. I estimate a workload of day to implement this. Follow the existing implementations to do so. You just would change scheduling order of jobs and children: If a job failed on a child, it is moved into a failed_jobs_ queue and only if all jobs are processed by the current child, the failed_jobs_ queue becomes the active queue.
There is one isse remaining with this approach: New jobs can arrive at any time, i.e. also if a subsequent child started to process the failed jobs. In this case, the semantics of the intended container will break as it needs to process those newly received jobs with the first child again.

[joseph-moore-CO]

Thanks for the detailed response - I did fear that this problem might not fit into the existing containers. Also, I recognise that this behaviour does go against some concepts of MTC by discarding potential solution branches before they are fully evolved.

I'll have a bit of further thinking to see if there's another way of achieving my aims, as I will need to have a good justification to commit the time to implementing a variant of the fallbacks containers.