Category: ArloBot

All of the bright colors are the graphical representation of ROS’s “Local Planner”. That is the part of the program that decides how to get from one place to another.

Making a map is one thing, but finding your way around an ever changing sea of obstacles is another.

Here I am simply testing whether the planner is detecting, marking and then clearing obstacles.

A couple of weeks ago it finally happened, my precious robot drive right down the stairs. Well, it drove over the threshold and tumbled down.

Amazingly the damage was limited.
The front caster was bent badly and no longer functioned properly.
A few bolts and screws were bent.
A few of the PING/IR sensor holders were shattered.

Thanks to Parallax though, my robot is already back in shape and on to new things!

Cliff Avoidance
I’ve done two things to reduce the possibility of this hazard.
1. I have a home brewed “home monitor” system that emails me when a door is opened.
So I added a sensor to the basement door and set it to place a file on the ArloBot’s hard drive. The safty_controller will monitor for this file and stop the robot if it exists:
It would be nice, though, to build a dedicated device for this purpose, because my home monitor system is very slow. I need something that can run on battery power and send messages over Wifi.

2. I added cliff sensors:
IR sensors works better for this than PING sensors because of their very narrow focus, which is what you want when you are just watching the floor.

If you look carefully you can see that there is one on each side of the front PING/IR sensor. They are simply taped to the surface with double sided 3M Auto Body Molding Tape so that it aims down slightly.

And I have modified the code that runs on the Propeller board to stop the robot if the distance on this sensor is too great:

I have not done very much testing with this yet. The biggest issue is that the robot needs to be aware of the cliff soon enough to stop and reverse before falling off of the edge. A sensor on the bottom pointing straight down is very reliable, but the robot will tumble before it has time to stop. By setting the sensor at an angle this gives more time to stop.

This shouldn’t be rocket science, but up until just this moment I never comprehended the <remap> tag.

However, due to a problem I was having I had the opportunity to track it down, in action, and also to see the result.

First, this is documented, but the documentation never made sense to me: http://wiki.ros.org/roslaunch/XML/remap

or for more confusion: http://wiki.ros.org/Remapping%20Arguments

So here is my explanation to myself:

If you look inside of my ArloBot propellerbot_node.py you will see that it listens to the topic cmd_vel:

rospy.Subscriber("cmd_vel", Twist, self._handle_velocity_command)

However, if you start up my ArloBot:

roslaunch arlobot_bringup minimal.launch --screen

and start driving it around with TeleOp:

roslaunch arlobot_teleop keyboard_teleop.launch

You will see NO cmd_vel topic!

In ROS there is so much going on that it is easy to chalk things up to “magic”, but when you actually write the Python code to listen to cmd_vel, and there is no cmd_vel topic, no amount of “magic” suffices. Obviously something is wrong!

The solution is <remap>, and the lesson is that this tag works on an individual node at the time we run it!

We called propeller_node.py with minimal.launch, and it includes the file mobile_base.launch.xml:

<include file=”$(find arlobot_bringup)/launch/mobile_base.launch.xml” />

and inside of this file is the “magic”:

The exciting line is this one:

<remap from="cmd_vel" to="mobile_base/commands/velocity" />

This says that when the node we are calling (propellerbot_node.py) tries to subscribe to “cmd_vel” give it “mobile_base/commands/velocity” instead!

Mystery solved, because that topic does exist!

Furthermore, if you run or create a node that sends data on the “cmd_vel” topic, nobody is going to listen to it!

I don’t know why these remaps were so confusing to me before. Probably because a lot of them are only used in the TurtleBot code that I borrowed from. Only when I had a clear situation where a third party node was talking on cmd_vel and nothing was happening did I realize that there IS NO cmd_vel topic in my normal setup, and yet it worked.

Question 2:

If I have a launch file that I want to start, and I know the node it starts will broadcast to a topic I don’t listen to, either directly or due to remapping, what can I do about this?

Based on this now less confusing documentation of argument remapping: http://wiki.ros.org/Remapping%20Arguments

You can also use remap when you run a node directly, so that this:

(This is based on a command from the great ROS by Example INDIGO book that you really should buy!)

rosrun rbx1_nav calibrate_linear.py

becomes:

rosrun rbx1_nav calibrate_linear.py cmd_vel:=mobile_base/commands/velocity

Because I know from experience (run the command and then run “rostopic list” to get that same experience) that this node broadcasts on “cmd_vel”, and from my previous discussion based on launch files and the output of “rostopic list” that my robot’s controller node listens on mobile_base/sensors/core

One of the motivations for building my robot was to be able to follow the tutorials and examples made for and written by ROS experts.

One of the best resources for ROS is ROS By Example – Volume 1 by R. Patrick Goebel. I’ve been waiting though for the “Indigo” version to be complete, because working with documents aimed at older versions of ROS is frustrating and time consuming.

Now it is here!
http://www.pirobot.org/wordpress/indigo-revision-of-ros-by-example-volume-1-available/

I plan to purchase this book and work through it with my ArloBot to become more familiar with ROS and learn to add more functionality to my robot.

I just now saw that the debs for ROS Indigo Turtlebot are listed in the install instructions now!

I have updated the ROS Indigo Setup article to describe installation using the Turtlebot Deb packages.

This is an index of the articles you can follow, in order, if you want to build my ArloBot:

1. Please see the Readme at my GitHub repository – https://github.com/chrisl8/ArloBot as it is usually kept more up to date. Then come back here and follow the instructions!
2. Buy lots of stuff – Arlo Robot Parts List
3. Build the Arlo – Arlo Robot Assembly Guide
4. Install Ubuntu – Laptop Setup for ROS Melodic
5. Install ROS and my code from Github – ROS Melodic Setup
6. Propeller Code – Propeller Code for Arlobot
7. Have fun!
   • ArloBot Recipes at the end of the Readme
   • Convenience Scripts

Mailing List: https://groups.google.com/forum/#!forum/ros-for-arlobot

While a lot of the fun stuff with the robot happens on the Ubuntu laptop with ROS, the motor control and sensor polling is all done on a Parallax Propeller microcontroller.

I like to think of the laptop as the cerebral cortex of the robot’s brain and the Propeller board as the Cerebellum.

The code for the Propeller is all written in C. I have set it up so that it will refuse to run into things even if ROS tells it to, and if it gets much too close to an object it will actually back away. This way it is safe to experiment with ROS without worrying too much about crashing into walls. You can also gently “push” the robot out of your way by just getting close to it and it will move away if it can. (Yes, you can “herd” your robot!) Obviously you still need to be careful, especially if you tell it to drive around extremely fast, because you can drive into a wall faster than the sensors are able to register it.

Here are the steps to get the C code that I use with my Arlobot ROS package onto your robot using the Ubuntu laptop you should have connected to it.

Follow all of these steps from your Ubuntu laptop. Because the laptop must be connected to the Propeller board via USB at all times for ROS to operate, it is natural to install SimpleIDE on the laptop and use it to update the code on the Propeller board when needed.

0. Learn first!
This isn’t a store bought toy, this is a learning project, so if you have never done anything at all with a Propeller board, I highly recommend insist that you go to http://learn.parallax.com/propellerc and follow some of the turtorials to get to know the Propeller chip, the Activity Board, SimpleIDE and Propeller C.
This will give you a good background to understand what is going on.
You can do this with just the Activity Board and your Windows computer, and then come back here later to make it all work with your Ubuntu laptop.
Without doing at least a few of the tutorials you will be following my instructions in the dark. They may get you to your destination, but it will be frustrating.

1. Add your user to the “dialout” group
Otherwise SimpleIDE tells you that you have no access to /dev/ttyUSB0

And then you will have to reboot to make this work.

2. Set up Parallax SimpleIDE for Linux

FYI: Parallax has abandoned support for Linux, as can be seen from this thread:
http://forums.parallax.com/discussion/166656/simpleide-on-linux

I am very sad about this, but it seems we can limp along by using copies of old code releases.

In the example below I show using ‘wget’ to pull the latest version of SimpleIDE from a web archive service (since Parallax has abandoned it) and installing the package on Ubuntu.

3. Test SimpleIDE
If it is not already done, plug your Propeller board into your Ubuntu laptop with the USB cable.

Open a terminal window in the Ubuntu desktop and run:

IF you get errors about missing dependencies, you may need to run:

The first time SimpleIDE runs it will create a folder with required libraries in it.
Please let it use the default location.

SimpleIDE should open with a “Hello World” program called Welcome:

Notice that I am using VNC to do this from the comfort of my desktop machine.

Make sure you see “/dev/ttyUSB” at the top right. It will probably be USB0, but if you have more than one board it could be another one.

Just run it with the terminal by pressing the blue terminal with the “play” arrow in it:

You should get a blue terminal window with the text “Hello!” in it, or whatever the simple test program was set up to send.
This proves that your SimpleIDE is installed and that your Propeller board is properly connected.
You can press “OK” on the Terminal window to close it and close SimpleIDE.

4. Add Arlo Code to SimpleIDE
For HB-25: The extra code from Parallax to work with the Arlo platform is already in my arlobot repository, you just need to copy it into your SimpleIDE folder structure.
If you already ran SimpleIDE once, and if you let SimpleIDE use default locations, this should work for you:

The library from Parallax to work with the Arlo platform is in a separate download on the Parallax site. Run these commands to download and “install” the library:
(NOTE: This copies files to the default folder created when you ran SimpleIDE for the first time.)

Run SimpleIDE again.
Open up ~/catkin_ws/src/ArloBot/PropellerCodeForArloBot/ROSInterfaceForArloBotWithDHB10.side
Click on the little hammer icon to just Build the code without loading it to the board.
If it says, “Building … done.” in green highlight then everything is good!
If it failed to build start trouble shooting or send me a note.

5. Learn Some More

I suggest working through the instructions here:
http://learn.parallax.com/tutorials/robot/arlo/arlo-activity-board-brain

This will walk you through testing your Arlo connections and basic code to operate the the Arlo platform from the Propeller Board. Even if you are using my code to run it, it will help you to deal with problems if you understand how the basics work.

6. Calibration

DHB-10: Calibration is not required for the DHB-10. There are steps on the site listed above (under Learning) for adjusting parameters, but calibration isn’t required.

HB-25 Controllers: ONLY DO THIS IF YOU HAVE THE OLD HB-25 CONTROLLERS! Otherwise skip to Step 7.
This step is a little complicated, so follow closely.
This is a combination of information from
http://learn.parallax.com/activitybot/calibrate-your-activitybot
and
http://www.parallax.com/news/2013-12-23/run-activitybot-c-code-arlo
but I’ve put it together here in one list of instructions.

The point of this is that you load special code into the board that, when powered on, causes the board to run a series of tests on the motors and then store the data into a special place in EEPROM. Once this is done you should never have to do it again, because no other program ever writes to this memory.

Note that this code is specially written by Parallax so that once it completes it will not run again. If you want to do the calibration again you will have to load the code into EEPROM again.
Otherwise, once it finishes once, resetting the board will not cause it to run again.

1. The instructions say to put your robot in a clear area to do this. I have also just put it up on “blocks” or a sturdy box so that the wheels can run freely without moving the robot. I’m not sure which, if either, is better.
2. Run SimpleIDE if it isn’t already running.
3. Open up the program ~/Documents/SimpleIDE/Learn/Examples/ActivityBot/Arlo Calibrate.c
4. Turn OFF the Motor switch.
5. Set the Activity Board switch to position 1.
6. Click the “Load EEPROM & Run button”
7. When the program is finished loading, the P26 and P27 lights will turn on. When they come on, slide Activity Board switch to 0.
Disconnect the USB cable from the Activity Board
8. Turn all power off. (Both Main and Motors switches OFF.)
9. Set the power switch on the Activity Board to 2. (It won’t come on yet because the power is off.)
10. Turn system power on but leave motor power off.
11. Press and release Activity Board’s reset button.
12. Wait a couple seconds.
13. Turn on motor power and wait for it to try to do something.
14. Press and release Activity Board’s reset again after the HB25s are convinced they are getting servo signals.
(This last step is required only during calibration because it’s crucial to capture all encoder measurements, from the very start of the program.)
15. Move back to give it room to spin in place and slowly roam while it gathers wheel speed data.
Both wheels should turn at some point. First it will spin in one direction, then the other. If one of the motors never comes on, you need to start over, because something went wrong.
(Or for the wheels to just spin if you have it up on “blocks”.)
16. Leave it alone until the P26 and P27 lights turn off (about 2 minutes). After that, calibration is complete and you can turn the power off again.

You can read more calibration trouble shooting tips here:
http://learn.parallax.com/activitybot/troubleshooting
although obviously some things, like the server adjustments, do not apply.

7. Edit the Propeller C Code for Arlobot to fit your setup.
In SimpleIDE Open up ~/catkin_ws/src/ArloBot/PropellerCodeForArloBot/ROSInterfaceForArloBotWithDHB10.side
Now at the top there is an entire section of “#define” statements.
You need to comment out some for items you don’t have, and you need to adjust the numbers after others to indicate things like how many PING sensors you have and where they are located.
By doing this, the code will be compiled to only include the parts you need and with setting specific to your robot.

8. Load Propeller C Code for Arlobot on to Propeller board.
The way the Propeller controller works is that if you load a program into “EEPROM” it will stay there and start any time the board is reset or power cycled. This means once the code is there you don’t have to mess with it again unless you want to change something.
If you get any of the “#define” settings wrong the first time, this could be one reason to reload it.

Plug the USB cable back into the Activity Board and Ubuntu Laptop.
Click the “Load EEPROM & Run button”

The board should load the code and reset.

Close SimpleIDE.
(NOTE: If SimpleIDE is running when you try to use ROS it will mess up the communication with the Propeller Board, so be sure to close SimpleIDE before testing anything.)

9. Testing.
A good way to test your Propeller code is to run:

It will start a test engine for testing everything about your robot before trying to run ROS.

Test all output, and attempt sending twist commands directly.
Until this works, do not expect ROS to work.

All done!

Remember, this is open source, so feel free to fix mistakes and make changes to the code and tell me about them! Better yet, fork the code and send me pull requests!
Next read over README.md, or try scripts from ~/catkin_ws/src/ArloBot/scripts/ and anything else from ROS that you want to try!
You can go to the ROS Turtlebot page and read about various functions it has and attempt to make them work with your robot.

P.S. Prevent Propeller Board from running on USB Power 
You may want to do this if you ONLY want the the Propeller Board to run from DC power and not the USB device.

I had a few spare hours over the holiday season so far to do some cleanup and add a few goodies I picked up from Parallax during their sales.

I’ll write more about my additions soon.

Along with my Arlobot ROS packages, I have also been working on a “Metatron” package that I use for some “personalization” of my robot, and a web interface called Arloweb.

I now have Metatron and Arloweb on my GitHub repository, so technically everything I use on my robot is on GitHub now.
In theory, if you follow my build to build the same robot I did, you can install everything from my GitHub repo and have a robot identical to mine.
Certainly more documentation is due, but at least it is all there and being updated as I modify the code.

If there is something in particular you want to do, let me know and I’ll try to document that ASAP.
As it stands now I kind of drift back and forth between documenting things I did months ago and things I’m working on now.

We have an xBox 360, so just like I was able to “borrow” the Kinect from it for initial testing, I am going to “borrow” one of the kid’s xBox controllers for testing! They rarely use all 4 anyway.

To use an xBox controller with a PC (Windows or Linux) you need a receiver, which are fortunately easily obtained.
I purchased this “Wireless PC USB Gaming Receiver for Xbox 360” from Amazon for under $10.

Note: I’m not sure if there is any way to “disassociate” an xBox controller from your xBox. You just connect it to a new device. I found that if I turned on the controller in another room it was far enough away that the xBox did not power on. If the xBox keeps turning on and grabbing your controller just unplug it from the wall so it has no power. Once your associate the controller with the PC adapter it shouldn’t turn on the xBox anymore.
Reconnecting it to the xBox should be as easy, just remember if you want to go back and forth you’ll have to keep doing this.

ROS already has a page about Configuring and Using a Linux-Supported Joystick with ROS. I will just be adding my findings specific for the xBox 360 and my ArloBot.

Before I plug in the adaptor my Ubuntu machine already shows one “js” device:

This appears to be some sort of accelerometer, possible built into the HP Elitebook laptop?!

That is not what I am after now, but it sure seems like I should look into it in the future! Maybe your laptop has one too?!

When I plug the USB adapter for the xBox joystick into my laptop I get four new “js” devices.

I guess since the xBox standard is to support 4 controllers, the USB PC adapter provides 4 devices right up front.

Press the button on the USB adapter and it starts flashing.
Press and hold the small round button on the back of the xBox controller that looks like “O)))” until the lights on top of the controller start to “spin”.

The light on the USB adapter will stop flashing almost immediatly and the lights on the controller will stop spinning and start flashing all together.
This part is confusing, because when the controller is connected to the xBox you get one quadrant lit up to show which controller it is. Instead on the PC I just get all 4 lights flashing at me, which is kind of annoying.

However, if you run sudo jstest /dev/input/js1 you will indeed see that Ubuntu sees the controller and it is the first one!

If your screen scrolls instead of updating the line of input in place try resizing your terminal window.

Clearly we have a LOT of input options here and a lot of cool buttons for doing all sorts of stuff!

It is kind of fun to play with and learn about how the controller works this way! 🙂

So now we carry on with the ROS instructions:

Make sure the js1 device is read/writeable by everyone:

You will need to have ROS running at this point, so if you don’t, start it.
If you don’t know what I mean, just open another terminal window and run roscore so it can be running over there while you carry on over here.

Now make sure your xBox controller is still on and run:

Now start another terminal (yeah, ROS is big on having dozens of terminals open to test things) and run:

It should be quiet as long as you do nothing, and then it should spit out lines like this if you push any button or move any stick:

A button push will give one entry for each up and down.
Moving an analog stick or button will send a lot of them as a stream of the analog output!

Now we know that ROS can see the input from your xBox controller!!!

One nice thing is that the ROS joy node can deal with the controller shutting down. With just jstest it would quit if the controller shut off or went out of range, but the joy node will keep attempting to reconnect, which you can even see in the output:

NEXT: Use the xBox controller and joy node to control ArloBot!

So now how do we make use of this in ArloBot?
Certainly we could write custom code and/or modify code to make use of the amazing arrow of inputs, but ROS already has code for this. Later I may augment this to make use of more of the buttons, but for now I’m going to try to just use what is included in ROS with as little modification as possible.

Don’t follow on with the ROS page we were at before, that was just to make sure we could see the controller in Linux and show us how to debug.
Now we want to find a node that we can use with ArloBot with the least fuss.

The easiest way to do this is to just launch ArloBot’s minimal bringup package and then launch turtlebot’s teleop:

The way this works is that it ONLY sends commands to the robot while the left “shoulder” button is held down. It is labeled “LB”. Hold that down and move the left stick and the robot should respond!
If things get out of hand just let go of the “LB” button and all zeroes will be sent again to make it stop.

And that’s it! It should work.

I will probably do some tweaking and customizing of my own joystick teleop code and include it in the ArloBot github repository soon. Until then though, the TurtleBot code is working fine.