Archive for May, 2015

Keeping Tabs on McGoon

by on May.31, 2015, under Project Goon

Time To Build 🙂

Last time I said we would start talking about, and maybe building, hardware.  Being a man of my word let’s get down to it…  Oh, before I forget, I got hold of a copy of Heiserman’s book (See the first post) and am in process of re-reading it.  I am finding that Peavy’s articles are a bit “lighter” than I desired so I went back to the start.  I will have updates from my reading in the near future, but for now Back to the Hardware!

WooHoo!  I love building things.  Software is awesome but it also my full time job so there is little diversion and relaxation in the software.  Building though is very therapeutic for me.

I said in the first post that I received a great set of Lego/Tetrix building stuff, so the build will be based on those.  First requirement down… Oh, did I forget to talk about requirements… Naughty Russ.


Requirements help us know what we want to do so we can figure out how to do it correctly.  The more time we spend doing requirements the better defined our project is, and the better its chances for success.  That said, this project is going to take an iterative approach to requirements.  We will define the basic ones, get started, and then re-visit requirements, design, and build as needed.  This is similar to the Agile process used for software development and it allows us to evaluate the success of the current set of requirements and make course adjustments without going back long distances.  So, what are the requirements we know right now:

  1. Use existing hardware components
  2. Three wheeled – Triangles are very stable (think tripods) and have a pretty tight turning radius
  3. Front two wheels are driven, back is an idler
  4. Must have a sensor to measure the magnitude of movement
  5. Built with room for adding sensors and other hardware as the project evolves

So, that is a REALLY simple list of requirements.  Obviously if I were doing this as a real engineering project the details in the requirements would be much, much greater.  Weight carrying capability, battery size and/or life, battery type, terrain capabilities, and the like are but a few of the things we would cover.  But, because this is a hobby/experiment project we won’t go quite that deep just yet.

Back to the Build

Okey Doke, Faux Pas recovered from, back to our hardware…  They say a picture is worth a thousand words, and I am a really bad typist…

Rough Sketch

A simple block diagram

Please excuse the rough sketch, but at this point I didn’t think it needed extreme detail.   I assume the driven wheels are fairly obvious (Please leave me a comment if you disagree and I will make sure to cover all the details).  Really, I think the piece that probably deserves the most attention is the Sensor/Idler wheel combination.  The purpose of the sensor on the idler wheel is to be able to give magnitude to the success of our movements.  What do I mean by magnitude?  Well, higher values for more “Successful” activities and lower values for less “Successful” ones.  As an example; for our robot, moving forward unencumbered is a VERY highly successful activity while going in a circle is certainly movement but it is a very low success rate because you never really get anywhere.  Being stalled is really no good at all, and neither is being stuck.  What is the difference between being stalled and being stuck?  Awesome question.

Stuck or Stalled? Why do we care?

The motors that will be used have shaft encoders on them.  If you are not familiar with a shaft encoder, its basic function is feedback to the computer about how fast and how far a motor is turning.  We’ll get into the specifics of “how far” once we get further into the design, but how fast needs to be measured so that we can make sure the wheels turn at the same rate when we are going straight or we will think we are going straight while we are really slowly going in a circle.  Soooo, back to being stuck versus stalled.  When any vehicle is stuck its drive wheels (tracks, treads, legs, etcetera) may continue to move even though the machine isn’t.  When a machine is stalled, the drive mechanism can no longer move.  If we were to use the shaft encoders by themselves to judge our magnitude we would ONLY know when we were stalled, not when we were stuck.  Imagine the robot going merrily along and Aunt Maud walks out in front of it.  The machine hits Aunt Maud, because we haven’t installed proximity sensors yet, which is bad enough, but because the motors are strong with the Force (Shameless Star Wars reference 🙂 ) the wheels don’t stop turning, no stall.  So now we have Aunt Maud screaming “Get this infernal contraption off’n me!!”, the dogs are barking like crazy, the robots wheels are starting burn a hole through Aunt Maud’s bunny slipper’s ear… Oh The Humanity!… all because the robot still thinks it is happily moving forward.   This is why we need the other sensor and cannot just rely on the movement of the drive wheels.

The Idler and the Sensor

Tetrix Omni-WheelSo the wheels (I think I am going to use two connected together) that will be used for the idler will be universal wheels (also known as Omni-Wheels).  These wheels have the unique ability to go in all directions.  This is accomplished with little wheels within the big wheel.  What this does for us is it allows us to mount the wheel facing forward without any pivot, but allows the robot to move in all directions freely.  If we monitor the forward/backward rotation of the wheel we will get a “magnitude” of how well we are achieving our goal.  If you want to review the goals they are here.  When the robot moves forward or backward the wheels will rotate forward or backward at a proportionate rate.  When the robot is turning, the wheels will rotate at a slower rate.  While going in a circle, stuck, or stalled, the wheels will not rotate at all. (I will post videos of these movements once the robot is built)  So how do we measure this movement?  Because of how the Tetrix wheel is made we can use a light sensor.  This type of sensor measures variable values of light and dark and is typically used for line-following robots that follow a dark line on a light background (or vice-versa).  If we mount it right above the wheel we can monitor the dark/light transitions of the wheel as it rotates, and Ta-Da! we have a way to monitor the magnitude of our movement.

I did consider using a pivot mounted idler and measure the rotation of the wheel (With pointing forward being zero degrees) along with the rotation, but I think this option will be simpler to implement.  The one concern I have is running the universal wheels on varying surfaces and how that will work.  This is one of those “Try it and see how it does” things, so that is exactly what I am going to do.

Well, I don’t know about you, but I am all “Worded” out at the moment.  The next post will be exclusively about assembling the robot, well it may take more than one, so be sure to check back soon.  For now, Have a great day!!

Leave a Comment more...

McGoon Begins

by on May.19, 2015, under Uncategorized


I promised to go over the three levels of AI we are going to be working on, but just a couple house cleaning items before that…

Please keep in mind that we are going to be discovering together.  I am not building, testing, debugging, and etcetera, ahead of time, we will be going through it all together.  So, if you are looking for a flawless tutorial, this ain’t it, but if you are looking to discover, make mistakes, learn, and have fun, you may like it here.

If you missed it I added an additional disclaimer to the bottom of the main page, so you might want to take a quick peek.

Back To Our Regularly Scheduled Program

The three levels of AI we are going to be working on, at least in the beginning, all have to do with moving.  Let’s face it, a robot that can’t move has limited use, where one that can run around can REALLY get into trouble.  Peavy covers this pretty well (see the first post for the reference), but I am going to go ahead and repeat it (my words, his information) just in case you don’t subscribe to Servo Magazine.

As a precursor to the level definitions we need movement definitions.  There are 9 basic patterns for the type of robot we are going to build:

  1. Stop – both drive wheels stopped
  2. Left Forward – Left motor forward, right stopped
  3. Left Reverse – Left reverse, right stopped
  4. Right Forward – Right motor forward, left stopped
  5. Forward – Both motors forward
  6. Counterclockwise – Left motor reverse, right motor forward
  7. Right Reverse – Right motor reverse, left motor stopped
  8. Clockwise – Left motor forward, right reversed
  9. Reverse – Both motors in reverse

Why are these patterns important?  Because they are the basis or McGoon’s “thinking.”  Like most things, McGoon will hopefully get smarter as we go along, but he is going to start at Alpha level intelligence.  Alpha Level is basically trying movements from the list at random until it achieves its goal.  Oops, I forgot to tell you about the goal, didn’t I…  The goal is movement, but only movement with magnitude.  By magnitude I mean “actually getting somewhere.”  If you look at the list above the only movements that really get somewhere are forward and reverse, all of the others either don’t move or just go in circles.  Beta Level remembers the successful attempts for a motion pattern and when in that pattern again, it tries the successful ones again.   When they work, it increases the “confidence” level, if it fails it decreases the level.  When it hits a motion pattern that has no movement records, it goes back to Alpha level behavior and picks at random.  Gamma Level will try several high confidence level movements from other motion patterns when it has no records for its current motion pattern before reverting back to Alpha level behavior.

So, to paraphrase; Alpha – random from a set list, Beta – Learn what works and apply in known circumstances before reverting to random, Gamma – Learn what works and apply it in both known and unknown circumstances before reverting to random.

Well, there it is…  Your five minute introduction to basic Artificial Intelligence as it applies to robotics. Doesn’t it make you feel all warm inside. 😛

That’s it for today, but next we talk about, and if there is time start building, the hardware to support this lovely AI Software we are going to write.

Until next time, Be Safe and call your mom, she worries.

Leave a Comment more...

Project Goon The Beginning

by on May.17, 2015, under Project Goon

Ancient History

Once upon a time when I was a young man (16) I built my first robot.  I was already building computers from scratch, so it wasn’t much of a stretch.  Now this robot was not particularly… ummm… shall we say functionally robust.  What it really was, was a radio control tank taken apart and re-tasked into a robot.  Sadly I have no pictures of my first creature, uh, I mean creation 😉  I took the treaded chassis, built a wood base, put a coffee can on that for legs, a box for a body, a piece of PVC pipe for a neck and a magic 8-ball for a head.  The head had two eyes that alternately flashed (LEDs and a 555 circuit)  The arms were hot red vacuum cleaner hose with fixed wire claws for hands.  I painted it and made the whole thing look really cool (at least to my 16 year old brain) and then showed it at the competitions for VICA (Vocational Industrial Clubs of America), now know as Skills USA, with two of my classmates who had built a larger robot.  Ever since that day I have been hooked…

What’s in a Name – Project Goon… HUH?!?!

Wondering where the project name came from?  Well, it is based on a couple of robot sentries from the Clive Cussler novel Dragon.  Their names, given to them by the character Al Giordino, were McGoon and McGerk and their job was to keep an eye on the book’s heros and keep them from causing their owners trouble.  The names stuck with me, being the nerd I am, and so I have used them in different projects over the years.  I was a coach for a USFIRST FTC robotics competition teams for three years and the last year our team was named Project GERK (Generalized Entity of the Robotic Kind), so I figured it was time for a project Goon.  I am still working on a clever acronym expansion, so if you have ideas drop me a comment.

How’d I Get Here?

I recently came into possession of a fairly significant set of Lego NXT and Tetrix Robotics parts which has opened up a huge opportunity for me to experiment without having to constantly buy new parts.  All of my other recent projects have involved robot kits, that once they were built and I finished what I was trying, they weren’t very useful for other things.  If you aren’t aware of this combination of parts, it has extreme flexibility, lots of good sensors, motors, servos, etcetera, and very solid aluminum structural components paired with Lego ease of use.  All I need to add is software, well a programming environment so I can write software, and then WooHoo!! I can start experimenting my brains out.

Where Are We Headed?

So what is project Goon?  Many years ago I read about, and drooled over but could never afford to build, a learning robot.  The book was How to Build Your Own Self-Programming Robot, by David L. Heiserman.  Since this was all the way back in 1979, I had long forgotten about it, but then while perusing the February, 2015 issue of Servo Magazine I ran into it again in an article by Camp L. Peavy, Jr., Rodney Junior: Smarter than the Average Robot.  The second installment is in the May, 2015 issue.  Camp’s articles renewed an old interest in me that I had wandered away from, learning robots.  I have built many robots over the years; radio control, autonomous, self-navigating, but never learning.  In case you haven’t figured it out yet… That’s what I am going to do in Project Goon.

The first phase in the project will be in keeping with Heiserman’s original work.  By that I am referring to the three initial levels of machine learning: Alpha (α), Beta (β), and Gamma (γ)  (This will be the discussion topic for the next post).  Once those three basic levels have been developed and tested, I will begin adding sensors for various purposes.  Hopefully somewhere around the third or fourth phase I am hoping to maybe add machine vision and object recognition, trying to keep the machine learning active throughout the project.

That’s it for today, but I will post more soon.  Stop back or follow me to keep up to date.

Leave a Comment more...


by on May.17, 2015, under Uncategorized

Well hello there!  I am so glad you decided to stop by.  If you read the main page then you know whats what, so I won’t re-bore you with the details.  If not, you may want to jump over there and take a look if for no other reason than to be able to tell your friends and family that you have done it. 😛

Enjoy the site and let me know what you think!

Leave a Comment more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!


A few highly recommended websites...


    All entries, chronologically...