Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pinchpoints - the thinking #63

Open
curthenrichs opened this issue Sep 25, 2021 · 0 comments
Open

Pinchpoints - the thinking #63

curthenrichs opened this issue Sep 25, 2021 · 0 comments

Comments

@curthenrichs
Copy link
Collaborator

Also the way I was thinking of doing pinchpoints is misguided/dumb. I had a (literal) shower thought. Pinchpoints are both static and dynamic and not exclusive to the robot. Machines have pinch points (which we should just treat as static - defined effectively as they are in EvD right now). There is currently no way of knowing in EvD that a static pinchpoint is tied to a particular machine or the robot or an interaction between robot and env. So here is what I propose. Machines had a property called pinch points which is a list. Any unclaimed pinchpoints are assumed to be the robot for now. Our feedback system should just give a warning that these pinchpoints exist and there is nothing we can really do about them existing. The operator should learn that these do exist. An example of a "static" pinchpoint on a machine is zone between blade conveyor and blade feeder (probably attached to the conveyor). An example of a "static" pinchpoint for a robot is its base proximity to the table (not a great example and may not be warranted - see dynamic pinchpoints). THE TAKEAWAY is static pinchpoints are provided a priori by an engineer to the novice / operator as illustration of the workcell. An operator is not expected to fix these but to learn of their existence and be cautious of them.

Dynamic pinchpoints are a violation of a minimum distance between two bodies.

Unpacking this, a minimum distance is dependent on what human body part can feasibly become trapped. I am thinking we keep it simple. I assume a person is standing straight up, then there is body cuboid/cylinder (generally), arm cylinder, hand cuboid /sphere (generally), and head cylinder. For the cylinders a single minimum distance is sufficient. For the body, orientation matters but we can treat it as a cylinder if we want to further generalize. The hands are tricky and are very much orientation dependent in 3D space. But again for this I think we simplify to a sphere. This gives us 4 heuristic distance measures we can think about. Furthermore if we assume the person is standing straightup (not great but simplifies things for now) then there is a band of heights where we consider each of the 4 pinch point distances. There is also a not-applicable filter. If the minimum distance is significantly less than the min distance for that part of the human then they couldn't possibly become trapped (we are not going to fit a persons body into a in space). That is not to say earlier in the program we created a situation where the human could get stuck. I thinking 25% below the human distance. Likewise above 50% human distance we have not yet approached an unsafe state.

As for the two bodies part, this is any two collision objects in the environment. Granted this is going to give false positives (e.g., pedestal) but I think we can live with that. I am not sure if we report all. We also need to think about the orientation of the line segment. Going back to the human model, the body cylinder is only concerned with horizontal x,y. Same with head. However arms and hands (simplified) are agnostic to orientation of line segment (generally).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant