I’ve been working in a dev branch of my Arlobot code for a long time now, and today I marged it into Master so there is a lot of new code there.
Hopefully it all works, but obviously I am the only one who tests it before you do.
A few of changes are:
1. I made a bunch of changes to the C code that runs on the Propeller Activity Board to try to make it more generic. You will have to answer a bunch of questions and comment out a bunch of #define lines to “customize” it for your setup, but hopefully it will be easy to do.
2. The automatic explore function should be functional now.
3. I’ve added some more smarts to the propeller_node.py script to make it more robust and give myself more ability to adjsut settings while the robot is running.
4. I added my code to make use of an XV11 “Neato” vacuum cleaner scanner that I bought.
At this point I’m also working a lot in my Metatron package to createa a nice GUI for interacting with the robot’s functions.
My next step once this is working will be to create a new setup routine that includes installing both the ArloBot and Metatron packages and bringing up the entire package.
It should work as either a monolithic “application” with a GUI or as a nifty set of convenience scripts along with access to all of the basic ROS functions that you can use on a TurtleBot. Whichever you prefer.
So head over to https://github.com/chrisl8/ArloBot and check out the commit history to see what is new and give the new code a spin if you are brave!
Or wait a week or two to see if anyone else discovers a major bug! 🙂
TODO: Write up a full wiring description with diagrams of every component . . .
The rest is just a collection of high resolution photos of the robot’s wiring. I hope these may help others imagine how to wire their ArloBot!
Click on each image for a full resolution version. Download them as you see fit and if you build a wiring diagram of your own please let me link to it! Or I can host it of course if you want.
If you have an Arlo Power Distribution Board, and you frequently leave your Activity Board plugged into a notebook computer when you turn off the Arlo Power Distribution Board, you may have noticed that the Activity Board stays on.
Furthermore, anything connected to the 5 volt supply on the Arlo Power Distribution Board stays on also.
The Activity Board is getting power from the USB port on the computer, and then it is passing this 5 volts on to other devices via the barrel connector.
I performed both steps 7 and 8 to ensure that mine would not run from USB power under any circumstances, because I never want it to do that on my robot.
Now your Activity Board will turn off when you turn off the Arlo Power Distribution Board and everything else will shut off too!
This also opens up the possibility to power cycle the Activity Board with the USB Relay Board. I have not done this yet, because I knew it was pointless as long as the Activity Board would continue to draw power from the USB port. I might try it now though, because sometimes I think a power cycle would be the most reliable way to force a reset on the Activity Board. All it would take is running the 6.5 volt wire through one of the relays before going to the Activity Board.
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:
C
1
2
3
4
5
6
7
8
9
10
11
12
for(i=5;i<7;i++){
if(irArray[i]>floorDistance){
safeToProceed=0;// Prevent main thread from setting any drive_speed
// Stop robot if it is currently moving forward and not escaping
if((Escaping==0)&&((speedLeft+speedRight)>0)){
drive_speed(0,0);
}
blockedF=1;// Use this to give the "all clear" later if it never gets set
blockedSensor[2]=1;// Pretend this is the front sensor, since it needs to back up NOW!
pleaseEscape=1;
}
}
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
/arlo_status
/arlobot/pirState
/arlobot_safety/safetyStatus
/arlobot_usbrelay/usbRelayStatus
/cmd_vel_mux/active
/cmd_vel_mux/input/navi
/cmd_vel_mux/input/safety_controller
/cmd_vel_mux/input/teleop
/cmd_vel_mux/input/web
/cmd_vel_mux/parameter_descriptions
/cmd_vel_mux/parameter_updates
/infrared_scan
/joint_states
/mobile_base/commands/velocity
/mobile_base_nodelet_manager/bond
/odom
/rosout
/rosout_agg
/serial
/tf
/ultrasonic_scan
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.
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?
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.
This is an index of the articles you can follow, in order, if you want to build my ArloBot:
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!
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
Shell
1
2
3
sudo adduser[your_user_name]dialout
i.e.
sudo adduser chrisl8 dialout
And then you will have to reboot to make this work.
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:
Shell
1
simpleide
IF you get errors about missing dependencies, you may need to run:
Shell
1
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:
Shell
1
2
3
4
5
# 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/
# ./PutFilesInPlace.sh
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.
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.
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:
Shell
1
2
cd~/catkin_ws/src/ArloBot/scripts/
./PropellerSerialTest.sh
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.
