Trajectory planning

[ashleshp]

The robotic arm should be able to calculate collision free/smooth way points to reach goal pose given in Cartesian space.

1. Cartesian Path Specification
2. Trajectory Generation
3. IK and FSM integration(ROS actions)
4. Error Handling & Logging

[vamsikalagaturu]

@rinaalo can we use moveit for our setup? if not, why?

[ashleshp]

@vamsikalagaturu Question was not for me but as per my current understanding ,
As things stand we can’t drop MoveIt directly into this stack because :
the URDF is exported without the MoveIt extras (moveit_active:=false) Here and the launch explicitly disables ros2_control src/eddie-ros/launch/eddie.launch.py:31). And also MoveIt’s planners expect to talk to a ros2_control joint interface (FollowJointTrajectory).

Also not sure we could use these somehow https://github.com/Kinovarobotics/ros_kortex/tree/noetic-devel/kortex_move_it_config

[vamsikalagaturu]

MoveIt’s planners expect to talk to a ros2_control joint interface (FollowJointTrajectory).

• This part is relevant, but not the previous ones.

It only partly answers my question, but not completely.

[ashleshp]

@vamsikalagaturu : Also our current eddie-ros package acts like a custom cartesian space controller.
It accepts a target pose via its ArmControl action server and internally computes the necessary joint
torques using KDL for IK . MoveIt however does not generate torques I guess and It generates
joint-space trajectories (series of time stamp joint positions/velocities) and expects to send them to
a "FollowJointTrajectory" action server which is a standard interface provided by ros2_control. The existing
eddie-ros controller does not expose this standard interface(same point as previous).

[vamsikalagaturu]

@vamsikalagaturu : Also our current eddie-ros package acts like a custom cartesian space controller. It accepts a target pose via its ArmControl action server and internally computes the necessary joint torques using KDL for IK .

Right. But its not IK. Its Inverse Dynamics

MoveIt however does not generate torques I guess and It generates joint-space trajectories (series of time stamp joint positions/velocities) and expects to send them to a "FollowJointTrajectory" action server which is a standard interface provided by ros2_control. The existing eddie-ros controller does not expose this standard interface(same point as previous).

Thats right on the implementation level.

@Robots4Sustainability/students Another question, why are we using Torque control?

[rinaalo]

@vamsikalagaturu The way I understand it: since the arm need to interact with objects, it need to move in response to contact, which is not really possible with position control. So if the arm used position control and contact an object it would keep pushing to reach the position, but with torque control it can react to the given force. This would also be useful for safety (in case a human interacts with the robot). And i think it's also useful for manipulating objects, such as how much force to apply while gripping an object (when torque limit is achieved, motor could stop moving and the object is gripped, so no more than required force is applied).

[ashleshp]

@vamsikalagaturu The way I understand it: since the arm need to interact with objects, it need to move in response to contact, which is not really possible with position control. So if the arm used position control and contact an object it would keep pushing to reach the position, but with torque control it can react to the given force. This would also be useful for safety (in case a human interacts with the robot). And i think it's also useful for manipulating objects, such as how much force to apply while gripping an object (when torque limit is achieved, motor could stop moving and the object is gripped, so no more than required force is applied).

Extending to @rinaalo reply : from use-case perspective torque control will be necessary while performing actions like unscrewing , pulling objects which are like snap in locks

[rinaalo]

@ashleshp well yeah those as well, but in general its useful for any interactions with the objects i think

[ashleshp]

@rina and @vamsikalagaturu Also from It allows the position controller to focus only on moving the arm from A to B, rather than also having to fight the constant, complex force of gravity. This results in smoother and more predictable movements. So calculating and applying the exact torque needed to counteract gravity, Else it'll constantly overshooting and oscillating