Most robots work in structured environments. They repeat the same actions all day. If there are many different locations all the coordinates for them are known and programmed. They never change. However there are unstructured situations where the coordinates the robot must go to are not programmed into the robot system but sent from some external system.

Most robots work in structured environments. They repeat the same actions all day. If there are many different locations all the coordinates for them are known and programmed. They never change.

However there are unstructured situations where the coordinates the robot must go to are not programmed into the robot system but sent from some external system. This is especially likely in an AI vision system where the camera might detect an object of interest and send the robot coordinates it can not reach. The robot system then throws up an error and stops.

ST Robotics are working on a mobile autonomous droid for harvesting asparagus where this can be a problem. ST are also working on a robotic kitchen where, again, the coordinates of an ingredient are not pre-programmed but are sent from a supervising AI vision system.


Here are some examples of where a human user has entered impossible coordinates into some well known robot systems:

For one well known robot arm a user wrote: "a get_inverse_kin() call raises a popup, pauses the robot program, and everything stops."
For another: " when i tried sending XYZ ABC the robot is moving to desired change in XYZ values but sometimes it stops throwing the 'Software Limit Switch Point cannot be reached'.
And for standard ST Robotics RoboForth simply: "Can't Reach'.

It's a problem for any robot in an unstructured environment. Therefore the robot should not error but simply refuse to try, optionally sending an error code back to the supervising software which can carry on with other tasks.

The cardinal rule has to be: no fatal errors.
To solve this problem ST Robotics have a special version of RoboForth, version M for machine. Not only does it handle impossible coordinates in a civilized manner but also many other possible errors, for example in the event of a collision the robot stops but does not throw up an error on the computer or teach pendant but sends an error code back to the supervising software and waits for a new command.

The result is safer, crash-proof software.


CEO of ST Robotics, serial inventor David Sands who conceived the idea says "This is another innovative solution unique to ST Robotics. To my knowledge no other robot company has this."


For more information please contact ST Robotics, New Jersey at +1 609 584 7522 or ST Robotics, Cambridge at +44 1223 420288 or visit our website at https://strobotics.com