Author Archives: paul

Arduino Micro and Adafruit Motor Shield V2

The Adafruit Motor Shield is a very well documented piece of electronics. Its capable of controlling 2 stepper motors or 4 dc motors with a additional possibility of moving 2 servo motors at once(!). So its perfect for small robot projects!
It has four phases of 1,4 Amps maximum current each with an even higher peak current – in case you cool it for instance by a fan it should even take more regular current like the chips datasheets promise. The voltage of the motors should be between 5 and 12 Volts (can be increased to 13 like most car batteries do have at least as long as I’ve connected it to mine for about 30 minutes).

The coolest thing about it is the I²C protocol (and the connected build in PWM-Chip) it speaks. Because of that its stackable with for instance other motor shields and can drive up to 96 Motors with a single i2c signal giver.
In most cases the signals come from the arduino family, more precisely the Duemilanove, Diecimila, Uno (all revisions), Leonardo and Mega/ADK R3 and higher. As you might recognized, there is no arduino micro in the list, but as it is just a smaller version of the Leonardo it should be possible to work too – right? The answer is: yes it does – at least if you solder right and find the connections that need to be made since the SDA and SCL Pins are digital 2 and 3 on the Micro and A4 and A5 on the shield. Adding 5V, 3V and ground is enough to get it running. (But keep an eye to short circuits and separate powering circuits for the micro)

The i²c protocol (I-squared-C) is supported by the [amazon &title=Raspberry Pi&text=Raspberry Pi] and the [amazon &title=CubieTruck&text=CubieTruck] which means hypothetical it should be possible to run the motor shield with that devices too, but I would not recommend to do so, as there is nearly no code library at the time of this post beeing written.

The motor shield comes with an arduino library where everything gets explained very well. Just one thing they forget to mention is the needed:

#define USE_USBCON

the motors
I’ve got to admit that the motors had been a bad joice so far – they are way to weak. I nearly drove me nuts to get them working, because I couldn’t believe how weak they are 🙂
So I’ve learned a lot about stepper motors datasheets and all of its very confusing unit handling the hard way. And I’ve done the mistake a lot of stepper motor newbies do: assuming the voltage needs to be the same as the batteries voltage. Avoid that thought in case you are building a robot currently 🙂

ROS Transformation and Odometry based on URDF Convention REP103

In order to get ROS working correctly, you need a lot things to be set up according to ROS defined conventions: for instance the ‘Standard Units of Measure and Coordinate Conventions’ (REP103), which clearly explains which units geometry_msgs.Twist should have or in what movement direction your robot need to be inside its URDF file.

For me this meant to redo my xacro (URDF-Macro) defined robot driving direction and its according tf-links. Since I’ve already gained some experience in creating robot models I tried to improve it a bit too:

I will explain the robots hardware setup in another post as soon as its possible to run it by keyboard teleop while publishing its accurate odometry. Odometry Messages aren’t simply ROS transformations like moving parts of the robot. Because the robot belongs to the physical world where for example friction exists and further wheel jamming could happen, all the calculated position data need to by verified. Qualified for this task is sensor data like Ultrasonic Sensor Ranges, motor potentiometer or stepper motor positions or Openni2 data provided by the [amazon &title=Xtion&text=Asus Xtion]. After publishing this Odometry messages to the /odom topic, the ros navigation packages can generate geometry/Twist messages to correct the position to mach the simulation again in case there has been some deviation.

More on this topic soon.

ROS Hydro / Indigo PointCloud to Laserscan for 2D Navigation

UPDATE: see my step by step guide for depthimage_to_laserscan here.

PointClouds need a lot of processing and network traffic load. For 2D navigation LaserScans are a good option to decrease this loads, in my case below to 30% of the original.

So after starting my customized openni2_launch (the launchers of openni_camera, and both ros drivers) with a custom Openni2 driver dir:

OPENNI2_DRIVERS_PATH=/usr/lib/OpenNI2/Drivers/ roslaunch /home/user/catkin_ws/src/robot_bringup/launch/openni2.launch

(OPENNI2_DRIVERS_PATH fixes all issues with the camera driver nodelet)

its possible to process this down to a /scan topic by:

rosrun depthimage_to_laserscan depthimage_to_laserscan image:=/camera/depth/image_raw

or directly in a launch file using the handy nodelet manager:

  <group>
    <node pkg="nodelet" type="nodelet" name="depthimage_to_laserscan" args="load depthimage_to_laserscan/DepthImageToLaserScanNodelet $(arg camera)/$(arg camera)_nodelet_manager">
      <param name="scan_height" value="10"/>
      <param name="output_frame_id" value="/$(arg camera)_depth_frame"/>
      <param name="range_min" value="0.45"/>
      <remap from="image" to="$(arg camera)/$(arg depth)/image_raw"/>
      <remap from="scan" to="$(arg scan_topic)"/>

      <remap from="$(arg camera)/image" to="$(arg camera)/$(arg depth)/image_raw"/>
      <remap from="$(arg camera)/scan" to="$(arg scan_topic)"/>
    </node>
  </group>

After that it is possible to visualize the new topic using rviz getting something like that:

of course the robot is still able to laserscan with the xtion (now in rainbow indicating z of the camera)

 

 

ROS is about: simulation, simulation and simulation …

ROS needs to know everything about the physics of a robot. It starts with dimension to avoid collusions – both with the outside world and the robot itself (e.g. if it is using two robot arms at once).  Further it is relevant where the sensors are – or in my case where the [amazon &title=Asus Xtion&text=Asus Xtion] is located in relation to the robots base. Another interesting information are the robots joints. Its needed to drive the wheels and to rotate the camera. For all that, a detailed description and representation of the robot in a format that a computer understands is essential.

Today I’ve made a hugh step in the simulation field, so struggeling with the motors in the real world for the last few days doesn’t feel too bad – at least I can generate some nice pictures now:

For me an interesting journey started, with a lot ups and downs – currently I am really excited where we will be in 18 weeks – because 2 weeks of my thesis already passed.

First experiences with the ROS Unified Robot Description Format

The Unified Robot Description Format is a nice way to describe robots in ROS. It is a xml formatted file which contains robot related information like links – geometry figures such as boxes, cylinders or sketch-up models(!), Joints – the information how the links are connected to each other, e.g. if they are fixed or continuous and in which state they are (using tf, the ROS transformation package)  – and a lot of more stuff I didn’t figure out after a day with .urdf.
There also is some macro language called xacro, which seams to be pretty amazing, reducing xml code length, enable the usage of variables in it (like for scaling a whole bot) and much more.

it may look simple, but this little robot took a complete evening. He has 2 movable wheels in the front, custom colors and hopefully will drive around in simulation soon:

ScreenshotAmosero_1 ScreenshotAmosero

It’s possible to generate a graphiz dot graph and a pdf from the urdf using following command:

urdf_to_graphiz path/to/file.urdf

after that open it e.g. by

evince file.urdf

looks like that:ScreenshotAmosero_2

Set vim filetype by its file extension

For my project I am constantly edition ROS .launch files, which are some kind of xml.

If I want to use syntax highlighting for better readability, I used to type :set filetype=xml . Which works, but gets kinda annoying in case you’ve got to type it multiple times a day.

In case you want to open .launch files with xml syntax by default, create a file in your .vim-folder:

mkdir $HOME/.vim/ #create the folder in case it doesn't exist yet
vim $HOME/.vim/filetype.vim #open it in vim

Change into insert mode (press i) and paste following code into it:

if exists("did_load_filetypes")
  finish
endif
augroup filetypedetect
  au! BufNewFile,BufRead *.launch setf xml
augroup END

Thats’s it, after that your vim will change:

before and default

before and default

after edits or set filetype=xml

after edits or set filetype=xml

Arduino Micro /Leonardo and rosserial Hello World possible link problem?

Yesterday I’ve had to learn something the hard way. Please have a look at the following code of the rosserial “hello world” arduino example:

/*
 * rosserial Publisher Example
 * Prints "hello world!"
 */

#include <ros.h>
#include <std_msgs/String.h>

ros::NodeHandle  nh;

std_msgs::String str_msg;
ros::Publisher chatter("chatter", &str_msg);

char hello[13] = "hello world!";

void setup()
{
  nh.initNode();
  nh.advertise(chatter);
}

void loop()
{
  str_msg.data = hello;
  chatter.publish( &str_msg );
  nh.spinOnce();
  delay(1000);
}

Nothing special, right? So compiling it – uploading everything on the arduino works like a charm.

But starting it  rosrun rosserial_python serial_node.py /dev/ttyACM0 crashes with:

rosrun rosserial_python serial_node.py /dev/ttyACM0
[INFO] [WallTime: 1400737593.278250] ROS Serial Python Node
[INFO] [WallTime: 1400737595.610358] Connecting to /dev/ttyACM0 at 57600 baud
/home/yourUser/catkin_ws/src/rosserial/rosserial_python/src/rosserial_python/SerialClient.py:317: SyntaxWarning: The publisher should be created with an explicit keyword argument 'queue_size'. Please see http://wiki.ros.org/rospy/Overview/Publishers%20and%20Subscribers for more information.
  self.pub_diagnostics = rospy.Publisher('/diagnostics', diagnostic_msgs.msg.DiagnosticArray)
[ERROR] [WallTime: 1400737595.826375] Error opening serial: could not open port /dev/ttyACM0: [Errno 13] Permission denied: '/dev/ttyACM0'

which can be easily explained by normal users missing permission to access the /dev/ttyACM0. So I advice running it as root, which leads you to customize roots .bashrc including the source /home/yourUser/yourWorkspacePath/devel/setup.bash and the environment variables like ROS_HOSTNAME and ROS_MASTER.

So after that, running it again with root permissions, you’ll get another error message:

[INFO] [WallTime: 1400737809.741920] ROS Serial Python Node
[INFO] [WallTime: 1400737810.415142] Connecting to /dev/ttyACM0 at 57600 baud
/home/yourUser/catkin_ws/src/rosserial/rosserial_python/src/rosserial_python/SerialClient.py:317: SyntaxWarning: The publisher should be created with an explicit keyword argument 'queue_size'. Please see http://wiki.ros.org/rospy/Overview/Publishers%20and%20Subscribers for more information.
  self.pub_diagnostics = rospy.Publisher('/diagnostics', diagnostic_msgs.msg.DiagnosticArray)
[ERROR] [WallTime: 1400737827.716961] Unable to sync with device; possible link problem or link software version mismatch such as hydro rosserial_python with groovy Arduino

So – rosserial tries to connect to your /dev/ttyACM0 using 57600 baud and fails. The error message is kind of misleading – of course there is some syncing issue, and it has nothing to do with your ROS version… …but with your arduino!

Since the arduino micro / leonardo uses USB for and its build in serial-controller both for programming and communicating, rosserial needs the information to access the device not in the for arduino usual serial way but with USB. So simply adding

#define USE_USBCON

before the rest of the code, will tell ROS to do so.

 

 

Ultrasonic Sensor HC-SR04 as a ROS Range publisher

I’ve taken a HC-SR04 like shown below and connected it to the CubieTruck as a rosserial publisher.

IMG_20140512_114741

 

Instead a of a simple std_msgs::String str_msg;  I’ve implemented a sensor_msgs::Range range_msg; which after starting the arduino in ros with rosrun rosserial_python serial_node.py /dev/ttyACM0  shows up in rostopic echo /ultrasound like this:

---
header: 
  seq: 136
  stamp: 
    secs: 1400706588
    nsecs: 709593997
  frame_id: ultrasound
radiation_type: 0
field_of_view: 0.10000000149
min_range: 0.0
max_range: 4.0
range: 1.18762886524
---

So with that, its possible to visualize everything using rqt_plot:

ScreenshotROSUltraSound

which is pretty nice for my first arduino micro ros project and less than an two hours of work 🙂

For further information see here

 

Raspberry Pi Robot #2

I’ve connected the [amazon &title=Raspberry Pi&text=Raspberry Pi] to an L298N and two 6V DC Motors, which have been in the Makeblock Starter Kit. I’ve had some issues with the WPA2 Enterprise TLS Network, which is why there is an cable attached.

IMG_20140521_164828

I’ve also written a small geometry/Twist controller for ROS-compatibility,for controlling the robots movement with keyboard interop like I did before.

Before I dismantle this little robot, I’ve like to share a little video:
Youtube Video

As soon as possible I will use the arduino micro and the two 250rpm stepper motors – for that I am planning to use a Arduino Motor shield that I’ve already ordered.

Howto use CubieTruck and NetworkManager to do WPA2 Enterprise TLS

Last days the [amazon &title=CubieTruck&text=CubieTruck] made me struggle with its Network behavior. It continuously refused to connect to any WLAN, didn’t allow the Usage of the NetworkManager GUI, and confused me a lot.

Some things that might help you:

Wlan isn’t enabled by default – or at least it wasn’t for me.

Load the driver

modprobe bcmdhd

In case you don’t want to do that everytime the [amazon &title=CubieTruck&text=CubieTruck] needs wifi consider adding a new line with ‘bcmdhd’ (no quotes) to /etc/modules

I needed to install the linux firmware:

sudo apt-get install linux-firmware -y

and reboot

sudo reboot

3. bring the wlan0 device up and scan if your wlan is available

sudo -i #get root 
ifconfig wlan0 up
iwlist wlan0 scan

Check if the /etc/network/interfaces file looks something like that:

auto lo eth0
iface lo inet loopback

No additional lines, or the NetworkManager will struggle with your devices, showing them as “not managed” or “disconnected”.

So by default lubuntu 13.04 image, no Network manager has been running by boot, so I’ve fixed that by adding following line to my /etc/crontab:

@reboot /usr/sbin/NetworkManager

(sure there are other ways – especially because it’s a system service)

So after reboot – using the [amazon &title=CubieTruck&text=CubieTruck]-GUI its faces you with a “Network Manager not running”.

Screenshot[amazon &title=CubieTruck&text=CubieTruck]

So the small Icon on the taskbar isn’t able to find the network manager.
I could not fix that other than by opening an LXTerminal and:

sudo killall nm-applet && sudo nm-applet

which leads me to a nice WLAN GUI and made it possible to use WPA2 Enterprise with TLS 🙂