“He’s just this guy, you know?”

The primary project I talk about here is my ROS based robot built on a Parallax Arlo platform.
If you want to know more about that start here:
Arlobot Build Index or check out some of my videos.

I am an active member at DevICT where I recently participatd in a Game Jam (I was part of the “What’s Up Chuck?” team) and I am a member at MakeICT.

I am also currently enrolled in online classes to finish my Bachelor’s degree at Fort Hayes State University.

Computers have been my hobby and passion since childhood. My hobby is to experiment with computers. My goal here is to share some of my projects for those who are interested and who may want to try some of these things themselves.

I love explaining things and teaching, so if you want more direction on how to make something work do comment and I will elaborate.

I have a full time job, but if you think I’m brilliant and want to pay me good money to experiment with computers for your company then feel free to contact me. 🙂

If you want a little background:
I am a Unix System Admin by trade.
I am working on a degree in Web Development.
I am teaching myself JavaScript.
And I like to play with computers.
In short, I am a jack of all (computer) trades, and master of none.

If you are wondering about the name see Of ????????? and Froods

Arlo Complete Robot System

Parallax has finally released a complete system package for the Arlo:

If you’ve been thinking of building one, it has gotten a lot easier now with the complete package. In fact my “parts list” dropped from a dizzying grocery list to essentially 3 items:

Also, TurtleBot is experimenting with a new 3D sensor to replace the Kinect/Xtion:

This should also help with sourcing parts as those have gotten harder and harder to find.

Merry Christmas

I’ve been over committed lately between work, education and family. So poor robot has been neglected.
I’m taking some time out for a needed break and hopefully starting the new year with more free time for hobbies.
For now I’m focusing on the important stuff.


(I guess the signal from so long ago and far away is having trouble getting through.)

I have a list of things to try next year though, so I’ll be back soon I hope.

Motor Power Up Order

So you got your robot built, installed everything, and the calibration worked, but now that you actually want to run the robot it does nothing.

The first thing is to turn it on and go use the ~/catkin_ws/src/Metatron/scripts/direct2PropSerialTest.sh script along with the recommended commands from ~/catkin_ws/src/Metatron/scripts/direct2PropSerialTestLines.txt to observe and test how everything works without ROS.
However, most people seem to either be doing this already, or be well past it, because you guys are really smart! 🙂

There is a hidden problem though. It is discussed in the calibration instructions, so I was assuming everyone knew about it, but I now realize it isn’t well explained.

Three separate people have contacted me with this issue, so I want to post it here on the blog.
The motor controllers have a strange quirk. Their “normal” mode does not work with the Propeller board! However, within the first few seconds after turning them on they listen for a certain kind of signal. If they get it, they flip to a mode that does work with the Propeller.

What does this mean? If you turn on the motors, then start everything up, the robot won’t do anything.

The solution: You have to wait until the Propeller board is fully running, after the first arlo_drive command has been sent to turn on the motors.
If you have PING sensors installed, you can know when it is time to turn the motors on by when the PING sensors start flashing.
The main thing is just to make sure the Propeller board is “initialized” before you turn on the motors. That means after the ROS arlobot program is already started, or after you sent the “i   0” to it via the direct2PropSerialTest.sh command.

Another solution? Get a USB Controlled Relay and wire it between the motor outputs on the Arlo Power Distribution board and the motor controllers. This way the code will actually turn on the motors at the right time. This is how mine is set up, and why I forget about this problem.

Kernel 3.13.0-65 may break Serial connections!

Yesterday, after updating to the linux-image-3.13.0-65-generic 3.13.0-65 Kernel on Lubuntu 14.04.3 LTS using the normal Ubuntu update/upgrade two different programs that rely on PySerial quit working. miniterm.py and my ROS (Robot Operating System) based Python node quit working.


To resolve your issue temporarily reboot, and at the “GNU GRUB” menu select “Advanced options for Ubuntu” and then move down to select the Ubuntu, with Linux 3.13.0-63-generic kernel option. (NOT the recovery mode one) and it should boot into the old kernel and work fine again.Reverting to the 3.13.0-63 kernel allows miniterm.py and other Python Serial based programs to work normally.

To fix the issue permanently: Remove the new kernel with:

and reboot,
which will remove the new kernel and remove it from GRUB.

There is a bug report open for this:
I also opened my own, but it is probably a duplicate of the above

Hopefully the next kernel patch won’t break it again.

Where am I?

Someone asked where I’ve been. What have TwoFlower and I been doing?

I have been quiet here because the robot has gone from a fever of building to slow steady background work.
My focus right now is to build an internal “behavior” system using Behavior3JS to allow the robot to “act” more independently.

The first goal is simply to have it intelligently go from “power on” to freely moving about the room. This may sound simple, but there are a lot of start-up tasks that need to be coded properly so that things are safe and sane.
Then the robot needs to know where he is,
load a map for that room,
know where he is in that room if point 0 on the map doesn’t happen to be it,
know if any doors in the room are open which might lead to dangerous stairs,
and unplug himself.

My github repo kind of shows my work days and progress https://github.com/chrisl8/Metatron/commits/master, but I realize it is also cluttered because I commit too often.

So here is a brief timeline of what I’ve been laboring away at:

June 16th – This is when I built the web based control panel that runs both on board and can be remotely accessed. This lets me control important parameters of the robot remotely and get him started remotely without having to run lots of scripts:

June 17th – I built a setup script to allow you to install everything from one command. This is documented on the front of my Arlobot repository now in the readme.

July 2nd – I added roslibjs to my Node based control panel so that ROS functions can be directly polled and controlled.

July 5th – I added the ability to set “waypoints” using the web interface. This means you can drive the robot to a position on the map, set a waypoint, and then in the future you can tell it to go to that waypoint again and it will return to the same spot on the map.
Now places like “Kitchen” and “LivingRoom” can easily be set and recalled.

July 7th – Added QR code reading. Now the robot can use a QR code taped to the wall to determine what room it is in as soon as it is started and automatically load the correct map for the room without any human intervention.

August 17th – Added the function for the robot to use a waypoint called “initial”, if found for the map, to set its initial “2D pose estimate” so if your normal starting point isn’t the same as point 0 on the map, the robot can automatically localize itself on startup.

Somewhere in there I also tweaked the “stop if a door is open” code and I installed a Moteino based door monitor on my basement door to alert the robot.moteino

Next I am working on the self unplugging routine. This isn’t super fancy. I just anchor the cord to the wall and have the robot back up, but once this works the robot can start up and go without human interaction!

So that is what I’ve been doing! 🙂

It excites me a lot when someone reaches out and asks what I’m up to and why no recent posts. So thank you!