How to turn the orientation of the Jackal Robot?

Question

Hello everybody,

We are using the Jackal robot from clearpath robotics for a project. We want to turn the default moving direction of the robot to the opposite. So the old forward direction should then be backwards. How can we achieve this?

We tried several things, but they did not work out.

Approach 1: We tried to change the base_link_joint of the urdf-model around 180°. After the turn of a coordinate frame around yaw=180°, the robot model behaves different in Rviz and Gazebo. If the model in Gazebo moves forward, the model in Rviz moves backwards.

 <joint name="base_link_joint" type="fixed">
    <origin xyz="0 0 0" rpy="0 0 ${PI}" />
    <parent link="base_link"/>
    <child link="chassis_link" />
  </joint>

The original urdf-model can be found on https://github.com/jackal/jackal/blob/indigo-devel/jackal_description/urdf/jackal.urdf.xacro

Approach 2: Turn the direction of cmd_vel. We changed the sign of the x-value of cmd_vel to move in the opposite direction. This leads to the correct movements in Gazebo and Rviz, but the robot moves in the opposite direction of the goal (which is understandable).

We also tried the modifications on the real robot, but the problems were the same.

EDIT:

I found a solution for the simulated robot by modifying the urdf: I've turned the base_link_joint around 180° and all 4 wheels also around 180°. Rviz and Gazebo behave like they should.

<joint name="base_link_joint" type="fixed">
        <origin xyz="0 0 0" rpy="0 0 ${PI}" />
        <parent link="base_link"/>
        <child link="chassis_link" />
</joint>

<xacro:wheel prefix="front_left">
    <origin xyz="${-wheelbase/2} ${-track/2} ${wheel_vertical_offset}" rpy="0 0 ${PI}" />
</xacro:wheel>

But when I want to use the same solution for the real robot. It does not change the moving direction. The model in Rviz changes when switching between different urdf-configurations, but the direction of movement stays the same.

Does anyone has an idea why this happens? And a solution how the real robot can get the same behaviour as the simulated one?

EDIT:

We did not found a working solution how to turn the orientation. We switched the configuration of the modules on top of the robot, so that we can use the default forward direction of the system.

Thank you for your help!

Greetings,

mr

---

Originally posted by mr on ROS Answers with karma: 11 on 2016-12-06

Post score: 1

Answer 1

To modify the internal semantics of which way base_link and etc. point in a standard robot would require some amount of modification, primarily to the robot description (jackal_description URDF). It should be enough to add a 180-degree rotation to any joint attached to base_link.

Because cmd_vel data is not stamped (attached to a reference frame), it is always in the base frame of the vehicle.

IMO, not worth usually worhwhile to modify URDF, since this a 'standard' piece that will be upgraded in apt periodically. If your higher-level code is feeding cmd_vel, consider writing a basic man-in-the-middle node.

If your higher level code is sending move_base goals, consider making it understand that the goal orientation should always face backwards.

---

Originally posted by paulbovbel with karma: 4518 on 2016-12-06

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by mr on 2016-12-08:
I tried to rotate any joint attached to the base_link and placed them correctly (the front_left_wheel is now really at the front left position etc.), but if I now move the robot forward in rviz, the simulated robot in Gazebo moves backwards. Do you have any idea why this happens?

Comment by mr on 2016-12-08:
If I sent the cmd_vel with the negated direction, the simulated robot and rviz behave in the same way, but this solution is not useable with move_base goals for the later application.

Comment by mr on 2016-12-08:
If I send move_base goals which are oriented and placed differently(backwards) to the robot, it leads to a backward movement with a rotation at the end to achieve the right orientation.

Comment by paulbovbel on 2016-12-08:
That's right, I guess the open-source planners are pretty biased towards forward movement.

So modifying URDF is probably your best option. If you're sure you've updated ALL joints attached to base_link, try playing around with the rotations in the tag of the wheel macro.