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! 🙂
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.
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.