Given the rather specific nature of the application, why not keep it simple and assume a box that matches the size of the table top + the occupant? It looks like the number of obstacles is low, they don't move (much) and there is no reason to skirt close to obstacles.Take the arm out, down then back in. If there are other obstacles in that path, wait for them to leave. Assuming this is x-ray or other radiation based, there aren't meant to be other people in the room anyway.

Thanks for your answer Jeffery,

I agree with your point about limited obstacles and I think I understand your point.

The way the system currently works is by a big handmade table with current position as input. The feedback from the table is something like your description:

1. Move "arm 1" to 75 cm in Z
2. Move body to 600 cm
3. If "arms are free" "turn body toward goal" else if "possible move arm 2 up".
4. etc.

I use the hit boxes show in the image to determine if a movement is possible or will result in collision.
The problem with that solution is that it is not very dynamic. The "stand" can be moved and the table can be moved by the user.

I have also made a system where smaller easy recognizable sub states are recognized:

1. If "Big movement" Move to body to 600 cm
2. If "arms need to switch places" do sequence 132
3. If "Goal position along tableside" do sequence 97
4. etc.

It made the task a little easier but still with the same problem, it is not dynamic. In a new situation where the "stand" is put in a new position and the table is turn, I have to make a lot of new add-ons to the table without affecting the already working part of the table.

Was it something like above you had in mind?

Jeffery you are right about the application of the robot.

I am very open to all ideas and I am grateful for all suggestions.

Edit:
Sorry, I was asked to remove the picture from the forum by my boss.

Hmm, okay. I think simplification still applies, just not *as* simple. ;) Perhaps a good approach would be to explore a virtual graph using A* with special actions. It might look a little more like a planner than a spatial graph. So for example, you allow free movement in a safe zone above the table, you have special actions for moving from above to below the table and vice versa, and you have special actions for moving while under the table. For moving above to below and vice-versa, treat it like a thick cylinder, e.g. move the arm so it's in it's most vertical position and move directly up and down. For moving while under the table, maybe treat the end as a sphere so no rotation could lead to collision.

The advantage would be simplicity and smarts. So if the arm is below the foot of the bed and wants to go to below the head of the bed, it would plot a direct course below the bed, sense a future collision (and abandon that node of the A* search), and then search special actions (move arm up), moving above the table, then special actions (move arm down). You may need to use a time slice based A* to avoid arm collisions with each other.

Edit: The up/across/down approach would of course work for arbitrary obstacles as long as they are simple and sparse. You would need to detect the general table position to start with. If you have depth data you could use a Hough transform or similar to detect a cuboid.

Thanks Jeffery,

It is a great idea. By using the A* as an action planner instead of has a pathfinder, I may be able to solve the problem. It opens a whole new set of options. I could do things like make some movement cost more than others. And as you suggest, it can use my preprogrammed sequences.

I think you are right (again ) - I need to make the A* time slice based. I will start working with your suggestion right away. It will not be easy, but hopefully it will work.

It would be a lot cleaner solution than with ANN.

Once again thanks.

Okay, thanks Dave Mark.

Hmm.. Automated planners is a whole new category of algorithm I didn’t knew about, so I think I need to make some research on the topic before I continue my work on the solution.

Info for other users at Gamedev:
The idea of planners
http://en.wikipedia.org/wiki/Automated_planning

STRIPS
http://en.wikipedia.org/wiki/STRIPS

GOAP ( Simplfied version of STRIPS)
http://web.media.mit.edu/~jorkin/goap.html


Ironic.. here is an game engine named “X-ray” which uses GOAP of NPC’s
http://en.wikipedia.org/wiki/X-Ray_Engine

Hello again,

Jefferytitan, your idea with A* as a planner worked. The system is now able to calculate a movement path.

But.. yeah.. there is always a but.. It is very slow.. it takes about 15 seconds to calculate. It is the simulation of the movement which determines if a movement will result in a collision which takes time, so I have to look in to some faster collision detection, but that is a whole other problem.

Thanks again.

I'm glad to hear it. I did suspect you might experience problems like that. Feel free to post another question on the collision. I imagine that (depending upon the format that you get obstacle data in) there will be easy ways to optimise the problem. If in doubt, try to solve a simplified version of the problem, and then drill down deeper if required. For example if you had obstacle data as voxels, you could do it octree style (e.g. if any child is an obstacle, mark the parent as an obstacle) and check for collisions first on a coarse version. If there may be an obstacle, then drill down.

You're dealing with motion planning here. Check out http://planning.cs.uiuc.edu/

Thanks Jeffery and Snowman,

To Jeffery: I’ll got some ideas on how to optimize collision detection, but if it don’t works I will probably post it as you suggested.

To Snowman: It looks like a very good and well written book. I think I will gain quite a lot by reading it.