VESC ROS brushless
motors ROS VESC

Differential drive ROS + VESC

Tonight I tested to control the motors with VESC over ROS and Differential drive. I took some time to get it setup. But a few hours later I could control the motor with keyboard_teleop over ROS. For a first test and only a few hours spent on this I am very happy with results.

I have not received any bullet connectors yet, so only one motor was plugged in tonight for this test. So the accutal Differential drive would be needed to be tested, but I can’t see why it should not work.

Thanks to the Morph project, there already was an ROS Driver which I could use. This meant I didn’t have to implement almost anything, Great! The Morph project uses the MIT-Racecar project open source VESC driver.

The Morph class ‘wheel_driver’ uses the vesc_interface class from the MIT-Racecar project to do the actual communication with the VESC. The wheel_driver is used in the class to drive the robot and registers two velocity joint interfaces named ‘left_wheel_joint’ and ‘right_wheel_joint‘.

ros_control a robot driver exposes joints which can be controlled using a velocity, effort or position interface. For wheels this means we need to implement the velocity interface. The velocity interface accepts the desired target speed as a command (in rad/s) and reports the actual speed as feedback of the current state (also in rad/s off course). The joints are controlled using a controller implementation, for which ros_control already provides some, including a differential drive controller.

In the morph.launch file some changes will be required.
First off you need to check and confirm the ports

<arg name="right_wheel_port" default="/dev/ttyACM0" />
<arg name="left_wheel_port" default="/dev/ttyACM1" />

To make the work easier in the future I would recommend to use udev rules to setup aliases for right/left wheel port. Ports tend to change and it can’t be hard to keep track on ports in a project like this. When using an aliases you will always know which port is which.

For example:
 <arg name="right_wheel_port" default="/dev/right_wheel_vesc" />
 <arg name="left_wheel_port" default="/dev/right_wheel_vesc" />

 

The next thing to check is the is the parameter for enabling rotor position publishing.

The default value is: <arg name="rotor_position_source" default="encoder" />

Possible values are “inductance”, “observer”, “encoder”, “pid_pos”, “pid_pos_error”, “encoder_observer_error” at the end of the file you need to modify the motor and wheel specifications.

<param name="right_wheel_ikv" value="8.821034775" />
<param name="left_wheel_ikv" value="8.543328017" />
<param name="tacho_pulses_per_revolution" value="90" />
<param name="motor_poles" value="15" />

Tomorrow I will continue trying to tune this further, I will also be testing two motors so I know everything works fine. I need to confirm the rotor position and confirm tech pulses per revolution for the hall sensors.

 

 

raess

Chief Technology Officer with a demonstrated history of working in the internet industry. Skilled in Business Planning, Computer-Aided Design (CAD), Quality Process Development, and SolidWorks. Strong business development professional with a Higher Education Diploma with specialization in Mechanical Engineering focused in Product development from Blekinge Institute of Technology.

http://valify.se

Leave a Reply

Your email address will not be published. Required fields are marked *