Image: Clearpath

Sriram Narasimhan’s research team are shaking things up in the Civil Engineering Structures Lab at the University of Waterloo. The research, which is led by Ph.D Candidate Kevin Goorts, is developing a new mobile damping system for suppressing unwanted vibrations in lightweight, flexible bridges. Whereas damping systems are often permanent fixtures built into the bridge, their system is designed to be adaptable, autonomous, and better suited for rapid, temporary deployment.

A SHIFT TOWARDS FLEXIBLE, LIGHT-WEIGHT STRUCTURES

Their work follows a recent industry shift towards using lightweight materials in the construction of civil engineering structures. Driven primarily by cost savings, as well as both the ease and speed of deployment, these lightweight structures could be a pedestrian bridge or a temporary bridge used in disaster relief scenarios, and are often more sensitive to external forces due to the reduced self-weight, and therefore require auxiliary damping devices.

Husky-based mobile bridge damping system on a full-scale aluminum pedestrian bridge. Image: Clearpath

HUSKY UGV: THE IDEAL MOBILE ROBOTIC PLATFORM

At the center of the team’s mobile control system is a Husky unmanned ground vehicle (UGV). An electromechanical mass damper mounted on top of the Husky is used to generate inertial control forces which are magnified by the body dynamics of the Husky. When situated on a bridge, the system is able to respond to changes in the structural response by autonomously positioning itself at the appropriate location and applying the desired control force.

For Goorts’ research, Husky UGV was the ideal mobile base upon which to develop their system. “The Husky is a rugged vehicle suitable for outdoor applications with sufficient payload capacity for both the damper and associated computational equipment.” said Goorts. “The low-profile and large lug thread tires are well suited for providing the necessary static friction to prevent sliding and transfer control forces. Moreover, Husky’s readily available ROS (Robot Operating System) integration allowed us to use several sensor types and position control algorithms.”

Linear motor and front-facing Kinect vision sensor mounted on Husky UGV mobile base. Image: Clearpath

The Husky is also equipped with a laptop running ROS and Kinect vision sensors on the front and back of the vehicle. Using wheel encoder data and measurements from the Kinect sensors, the system is able to perform SLAM (Simultaneous Localization and Mapping) and autonomously navigate back and forth along the span of the bridge. One of the immediate challenges the team faced was getting the robot to accurately localize on a bridge with a repetitive structural design – everything looked the same to the robot from different positions. To overcome this, they placed unique AR (augmented reality) tags along the bridge between which the robot could navigate.

A National Instruments (NI) cRIO is being used for all data processing tasks and execution of the structural control loops, and a TCP data link communicates between the ROS laptop and cRIO. Image: Clearpath.

BRIDGE VIBRATIONS REDUCED BY 70%

The effectiveness of the control system is tested using real-time hybrid simulation (RTHS), a dynamic testing method that couples the physical control system with a numerical model of the structure. These tests were carried out on a full-scale aluminum pedestrian bridge with re-designed panels to measure the forces being applied by the system. Results from the simulations show the system can provide up to a 70% reduction in the lateral displacement of the bridge.

The current prototype is suitable for bridges with a mass up to 1-tonne and is scalable to accommodate larger structures, either with a larger vehicle or with multiple vehicles that work cooperatively. Looking forward, the team is exploring the idea of making the system vehicle agnostic, which could allow any vehicle to be turned into an autonomous bridge stabilizing machine.

The post Customer Story: Deployable, Autonomous Vibration Control of Bridges Using Husky UGV appeared first on Clearpath Robotics.

If you liked this article, you may also be interested in:

• Clearpath Robotics launches “Warthog UGV”, the amphibious robot
• Interview: International Ground Vehicle Ground Competition (IGVC) winner on “Bigfoot 2” Husky UGV
• 4 reasons why Industry 4.0 will leave AGVs behind
• 5 innovation challenges in materials transport
• Clearpath and Christie demo 3D video game with robots

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

The Arduino family of micro controllers has quickly become a go-to board for hobbyists due to its ease of use. Often times roboticists must create communication protocols to allow their embedded hardware to communicate with a computer. One of the most powerful aspects of ROS is that it can communicate with a large variety of hardware. That’s where rosserial comes in! Rosserial is a general protocol for sending ROS messages over a serial interface, such as the UART on Arduino. This allows you to easily interface any sensors attached to Arduino into your ROS environment. Read on to learn more!

This tutorial will get you started  by setting up the Arduino IDE and installing the rosserial libraries. Then, we’ll test it out by driving the Husky simulation using a neat trick with the Arduino board. It should goes without saying you’ll need an Arduino to complete this tutorial. We’ll also be using a Husky simulator, so make sure to run through our “Drive a Husky” tutorial if you haven’t done so yet.

Setup

The first step is to set up your Arduino environment, begin by installing the Arduino IDE and rosserial using:

sudo apt-get install arduino arduino-core ros-hydro-rosserial ros-hydro-rosserial-arduino

Once you open up the Arduino IDE for the first time, a directory named “sketchbook” will be created in your home directory. Now we need to import the rosserial library into your arduino IDE. If your sketchbook directory is empty, you may need to create a directory named “libraries” inside of it.

mkdir ~/sketchbook/libraries
cd ~/sketchbook/libraries
rosrun rosserial_arduino make_libraries.py .

Restart your Arduino IDE and you should see the ros_lib part of your libraries!

You’ll want to ensure that your Ubuntu user is part of the “Dailout” group, which grants you access to serial ports. You can check by using

groups "username”

If you don’t see “dailout”, you can easily add yourself using

sudo gpasswd --add "username" dialout

One last step to make our lives easier will be to create udev rules so your Arduino is  recognized when plugged in and the correct permissions are set. For more information on udev rules check out our udev article . Begin by plugging in your Arduino.

NOTE:If you are using a virtual machine, you will have to connect Arduino to the virtual machine after plugging it in.

You can confirm your system is actually connected to Arduino by running

ls -l /dev

Depending on your specific Arduino board, you should either see a line with ttyAMC# or ttyUSB#, where # is a number. This will also tell you the current permissions for your Arduino. Chances are you wouldn’t be able to upload code to your Arduino at the moment because you don’t sufficient permissions, but we will soon solve that by creating a new udev rule!

The udev rule will require the product and vendor ID to be able to identify when our arduino is connected which you can easily find using

lsusb

You should see a line similar to

Bus 002 Device 005: ID 2341:0043

To confirm this is indeed your Arduino, disconnect it and run the command again, taking note which entry has disappeared. Remember the ID numbers, in this case, 2341 is the vendor ID and 0043 is the product ID. Now venture over to your udev rules at:

cd /etc/udev/rules.d/

and create our new rules file, the naming conventions for rules files follows “##-name.rules”. Chose a number that isn’t in use!

sudo gedit 97-arduino.rules

Copy the following into your new rules file, replacing #### with your product ID and vendor ID. For more information about what these tags mean, check out our article on udev rules.

SUBSYSTEMS=="usb", ATTRS{idProduct}=="###", ATTRS{idVendor}=="####", SYMLINK+="arduino",MODE="0777",

All that is left is to update your udev rules and reboot your system

udevadm trigger
sudo reboot

You should now see “arduino” as an entry in ls -l /dev with full permissions! (rwxrwxrwx)

Code

We’re now set to upload our code to Arduino! The code is fairly straight forward, however if you have any difficulties following along, check out our “Creating a publisher” tutorial. Copy the following code into the Arduino IDE and click upload. If your udev rules were set correctly you should be able to upload without any errors.

If you encounter any errors, verify your arduino is coming up as “arduino” in a ls -l /dev and proper permissions are set. You may also have to point the Arduino IDE towards the correct USB port in tools -> serial port.

#include <ArduinoHardware.h>
#include <ros.h>
#include <geometry_msgs/Twist.h>

ros::NodeHandle nh;

geometry_msgs::Twist msg;

ros::Publisher pub("husky/cmd_vel", &msg);

void setup()
{
 nh.initNode();
 nh.advertise(pub);
} void loop()
{
 if(digitalRead(8)==1)
 msg.linear.x=-0.25;
 
 else if (digitalRead(4)==1)
 msg.linear.x=0.25;
 
 else if (digitalRead(8)==0 && digitalRead(4)==0)
 msg.linear.x=0;
 
 pub.publish(&msg);
 nh.spinOnce();
 }

Driving Husky

Now that Arduino is loaded with our code and publishing velocity commands, we can pass these messages along into our ROS environment. We’ll start by launching a Husky simulation:

roslaunch husky_gazebo husky_empty_world.launch

All that’s left is to attach the Arduino into our ROS environment using:

rosrun rosserial_python serial_node.py _port:=/dev/arduino

We’re ready to try it out! Go ahead and touch the digital pin 8 and you should see Husky drive forward! Similarly if you touch digital pin 4 Husky will drive backwards.

This trick is made possible by a phenomenon known as parasitic capacitance, which is usually an unwanted effect in electronics design, but serves nicely for the purpose of our example. That being said, this isn’t the most reliable method, and is intended to provide a simple example with minimal equipment.  If you are having difficulties moving your simulated Husky, try using rostopic echo /husky/cmd_vel to verify some commands are in fact being sent to Husky when you touch the pins.

Be sure to go through the rest of our ROS tutorials on our knowledge base. If you want to learn more about rosserial, be sure to visit the rosserial page of the ROS wiki.

Looking for other Clearpath tutorials? You might like these ones! Or visit www.support.clearpathrobotics.com.

Happy Birthday!! Clearpath is officially 5 years old and what better way to celebrate than let all of our fans drive a robot. No matter where you are in the world, you can experience what it’s like to drive Husky – well, a very mini, hacked-together Husky that is. We’ve put together ‘twit-bot’ for your enjoyment so you can move our bot around all from the convenience of your smartphone using Twitter.

Here’s how it works:

Step 1: Mention Clearpath’s Twitter handle (@ClearpathRobots)
Step 2: Hash tag #MoveRobot
Step 3: Write the action you’d like it to take (examples are below)
Step 4: Watch it move on the live feed: http://www.twitch.tv/twitbot_cpr
Step 5: Share with your friends!

How does it move?

This little twit-bot can go just about anywhere and in any direction using the commands below (case insensitive).  The delay between the tweet and the streaming is about 30 seconds:

• “forward” or “fwd”
• “backward” or “bck”
• “right” or “rght”
• “left” or “ft”
• “stop” or “stp”

You can also tweet colors to change the colors of the LED lights: blue, red, white, etc.

If you liked this article, you may also be interested in Clearpath’s ROS 101 Tutorials:

• ROS 101: Intro to the Robot Operating System
• ROS 101: A practical example
• ROS 101: Drive a Husky!

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

In the previous ROS 101 post, we showed how easy it is to get ROS going inside a virtual machine, publish topics and subscribe to them. If you haven’t had a chance to check the out all the previous ROS 101 tutorials, you may want to do so before we go on. In this post, we’re going to drive a Husky in a virtual environment, and examine how ROS passes topics around.

An updated version of the Learn_ROS disk is available here:

https://s3.amazonaws.com/CPR_PUBLIC/LEARN_ROS/Learn_ROS-disk1.vmdk
https://s3.amazonaws.com/CPR_PUBLIC/LEARN_ROS/Learn_ROS.ovf

Login (username): user
Password: learn

If you just downloaded the updated version above, please skip the next section. If you have already downloaded it, or are starting from a base install of ROS, please follow the next section.

Updating the Virtual Machine

Open a terminal window (Ctrl + Alt + T), and enter the following:

sudo apt-get update
sudo apt-get install ros-hydro-husky-desktop

Running a virtual Husky

Open a terminal window, and enter:

roslaunch husky_gazebo husky_empty_world.launch

Open another terminal window, and enter:

roslaunch husky_viz view_robot.launch

You should be given two windows, both showing a yellow, rugged robot (the Husky!)

The first window shown is Gazebo. This is where we get a realistic simulation of our robot, including wheel slippage, skidding, and inertia. We can add objects to this simulation, such as the cube above, or even entire maps of real places.

The second window is RViz. This tool allows us to see sensor data from a robot, and give it commands (We’ll talk about how to do this in a future post). RViz is a more simplified simulation in the interest of speed.

We can now command the robot to go forwards. Open a terminal window, and enter:

rostopic pub /husky/cmd_vel geometry_msgs/Twist -r 100 '[0.5,0,0]' '[0,0,0]'

In the above command, we publish to the /husky/cmd_vel topic, of topic type geometry_msgs/Twist, at a rate of 100Hz. The data we publish tells the simulated Husky to go forwards at 0.5m/s, without any rotation. You should see your Husky move forwards. In the gazebo window, you might notice simulated wheel slip, and skidding.

Using rqt_graph

We can also see the structure of how topics are passed around the system. Leave the publishing window running, and open a terminal window. Type in:

rosrun rqt_graph rqt_graph

This command generates a representation of how the nodes and topics running on the current ROS Master are related. You should get something similar to the following:

The highlighted node and arrow show the topic that you are publishing to the simulated Husky. This Husky then goes on to update the gazebo virtual environment, which takes care of movement of the joints (wheels) and the physics of the robot. The rqt_graph command is very handy to use, when you are unsure who is publishing to what in ROS. Once you figure out what topic you are interested in, you can see the content of the topic using rostopic echo.

Using tf

In Ros, tf is a special topic that keeps track of coordinate frames, and how they relate to each other. So, our simulated Husky starts at (0,0,0) in the world coordinate frame. When the Husky moves, it’s own coordinate frame changes. Each wheel has a coordinate frame that tracks how it is rotating, and where it is. Generally, anything on the robot that is not fixed in space, will have a tf describing it. In the rqt_graph section, you can see that the /tf topic is published to and subscribed from by many different nodes.

One intuitive way to see how the tf topic is structured for a robot is to use the view_frames tool provided by ROS. Open a terminal window. Type in:

rosrun tf2_tools view_frames.py

Wait for this to complete, and then type in:

evince frames.pdf

This will bring up the following image.

Here we can see that all four wheel are referenced to the base_link, which is referenced from the base_frootprint. (Toe bone connected to the foot bone, the foot bone….). We also see that the odom topic is driving the reference of the whole robot. This means that if you write to the odom topic (IE, when you publish to the /cmd_vel topic) then the whole robot will move.