Ask Your Question

Revision history [back]

Also http://answers.ros.org/question/216101/stewart-platform-how-can-i-connect-multiple-joints-to-the-same-child-link-but-different-parent-links/ and http://answers.gazebosim.org/question/3696/how-to-simulate-a-stewart-platform-with-gazebo-and-ros/

https://en.wikipedia.org/wiki/Stewart_platform looks like the platform would involve a tf frame with six parents, but multiple parents aren't allowed in urdf.

Perhaps it is allowed in Gazebo with SDF? In that case you would need to have gazebo-only code/scripts/launch files that launches the platform, then some bridging code that gets transform info from gazebo and publishes it into ros. This could evolve involve a ros-gazebo plugin later, and within urdf the user would specify the general parameters of the platform.

You could do something with Gazebo very hacky and cpu intensive and possibly unstable simulation-wise involving a platform that isn't actually parented to the actuators but is physically constrained by mostly interlocking collision objects.

You could make or perhaps find some off the shelf stewart platform code that solves for the orientation of the platform and the actuators given how much the actuators are extended and run it in a ros node, and that would publish those transforms for the actuators and the platform.

Also http://answers.ros.org/question/216101/stewart-platform-how-can-i-connect-multiple-joints-to-the-same-child-link-but-different-parent-links/ and http://answers.gazebosim.org/question/3696/how-to-simulate-a-stewart-platform-with-gazebo-and-ros/

https://en.wikipedia.org/wiki/Stewart_platform looks like the platform would involve a tf frame with six parents, but multiple parents aren't allowed in urdf.

Perhaps it is allowed in Gazebo with SDF? In that case you would need to have gazebo-only code/scripts/launch files that launches the platform, then some bridging code that gets transform info from gazebo and publishes it into ros. This could evolve involve a ros-gazebo plugin later, and within urdf the user would specify the general parameters of the platform.

You could do something with Gazebo very hacky and cpu intensive and possibly unstable simulation-wise involving a platform that isn't actually parented to the actuators but is physically constrained by mostly interlocking collision objects.

You could make or perhaps find some off the shelf stewart platform code that solves forward kinematics for the orientation of the platform and the actuators given how much the actuators are extended and run it in a ros node, and that would publish those transforms for the actuators and the platform.

platform. (And you already need inverse kinematics solved to make the system useful, though perhaps you were hoping the forward kinematics from a generic simulation would validate your special case inverse kinematics...)

update

I've made a ros node https://github.com/lucasw/simple_sim_ros that is a light wrapper around the bullet physics simulator, and it can create a stewart platform:

image description

image description

It is lacking important features like closed loop actuator control, currently it can only take impulses rather than actuator extension commands, but I'll add that later.

Old answer

Also http://answers.ros.org/question/216101/stewart-platform-how-can-i-connect-multiple-joints-to-the-same-child-link-but-different-parent-links/ and http://answers.gazebosim.org/question/3696/how-to-simulate-a-stewart-platform-with-gazebo-and-ros/

https://en.wikipedia.org/wiki/Stewart_platform looks like the platform would involve a tf frame with six parents, but multiple parents aren't allowed in urdf.

Perhaps it is allowed in Gazebo with SDF? In that case you would need to have gazebo-only code/scripts/launch files that launches the platform, then some bridging code that gets transform info from gazebo and publishes it into ros. This could evolve involve a ros-gazebo plugin later, and within urdf the user would specify the general parameters of the platform.

You could do something with Gazebo very hacky and cpu intensive and possibly unstable simulation-wise involving a platform that isn't actually parented to the actuators but is physically constrained by mostly interlocking collision objects.

You could make or perhaps find some off the shelf stewart platform code that solves forward kinematics for the orientation of the platform and the actuators given how much the actuators are extended and run it in a ros node, and that would publish those transforms for the actuators and the platform. (And you already need inverse kinematics solved to make the system useful, though perhaps you were hoping the forward kinematics from a generic simulation would validate your special case inverse kinematics...)