bsBlog

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

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…

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

So 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!!