UR5 robots mounted on a network of rails.
I have two UR5 robots mounted on a network of rails. Currently, the network is just one straight line with the robots each spawning on opposite ends of that straight line. Each robot shares a common rail link and is attached to it via a prismatic joint. I want to now extend this scenario to a case where the network is more complex with forks etc. However, in this case, I am not sure how to go about specifying the joints such that when a robot reaches a fork, it changes its prismatic joint axis to go along one direction. Any pointers regarding this will be really helpful! I have attached an image of what the railway network could like.
.
Not an answer, but perhaps you could see what people do in Gazebo when simulation trains. I seem to remember there was at least one person who achieved something like that. Not sure whether they also had forks in their network though.
For a plain ROS approach: in absence of something existing, perhaps a custom TF broadcaster with knowledge of the layout of your tracks would be the most straightforward.
I did take a look at some Gazebo simulations. The ones I found were either a single straight rail or a variant that was a little bit close to what I want. In that variant, the robot was mounted on a rail following one axis(y) which itself was mounted on another rail on a perpendicular axis(x). However, the problem for me with that approach is that it would cause the first rail to move as well as it is mounted on the second one. That would not be ideal for cases where I want two robots to be able to cross each other if required.
Could you please elaborate a little bit more on how TF broadcaster can help in resolving this issue? Can one change the prismatic axis of a robot joint via that method? It is not clear to me yet as to how to go ...(more)
I specifically mentioned simulations of trains. Those are potentially very different from robots on rails, which is what you seem to have looked at.
why limit yourself to a prismatic joint? A TF broadcaster is free to publish whatever 6D transform it wants.
You won't be able to easily use a
joint_state_publisherfor that "joint" (which it isn't really any more), but who cares.So would this approach mean that I write a custom TF broadcaster for the joint between the track and the robot. How would that reflect in the Gazebo/Rviz framework? Would it also require to publish the position of that joint in the
joint_statestopic? I tried to make this work but I am not able to visualize the effect. I can see by looking at thetfandjoint_statestopics that the new value was published but I could not see any change in the simulation.