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!
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:
safeToProceed=0;// Prevent main thread from setting any drive_speed
// Stop robot if it is currently moving forward and not escaping
blockedF=1;// Use this to give the "all clear" later if it never gets set
blockedSensor=1;// Pretend this is the front sensor, since it needs to back up NOW!
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.
chrisl8@ArloBot (master *) scripts $ rostopic list
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:
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.
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?
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.
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 recommendinsist 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
sudo adduser chrisl8 dialout
And then you will have to reboot to make this work.
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:
sudo apt--fix-broken install
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:
# Do NOT run these lines unless you have the OLD HB-25 motor controllers!
# cd ~/catkin_ws/src/ArloBot/ArloBotParallaxLibraries/
# or if that does not exist
# cd ~/catkin_ws/src/ArloBot/OldArloBotParallaxLibrariesForHB25/
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.
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.
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.
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.
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.
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.
Along with my ArlobotROS 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.
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.
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!
Make sure the js1 device is read/writeable by everyone:
Make /dev/input/js1 a+rw
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:
Set Joystick Device
rosrun joy joy_node
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.