Time...

The end of August, the end of another summer gone in no time. Leaves beginning to fall, plans uncompleted, lawns not mowed enough, flower beds unattended, and projects still in the same status of spring. Each month seems to pass faster than the previous without warning and without slowing down. The "busy-ness" of the work week burns out the motivations of the evenings and weekends. Eat, work, recover, sleep, eat, work.... well, I guess there are more "eat" steps in there for me than there should be, but the routine is similar. I used to think that life would slow down as you age, you'd have time to appreciate it more and feel more accomplished. Not happening here at least. So much to do so little time to do it seems the standard. Time marches on, accomplishments do not. 

I do stop, however, and appreciate what I have, often. I can walk, I can work, I can play, and I do have more free time than many around the world. I have a job, I have a family, I have a house and the things that go with those the good Lord has given me. I have good health, as compared to many, which is the one of the most important of all. I actually can do things I want to do for the most part without assistance or other resources. I can even sit here wasting time writing and complaining that I don't have time to do things.... Oh, wait... I just need that time expansion tool but I don't have enough time to work on it! Oh the conundrums of life. :-)

Life Changes...

It's funny how changes in life seem to sneak up on you although you known it was coming for a long time....

The latest example is sending our wonderful son Austin off to college. Sure, we knew it was going to happen, knew he was going to move on to his new chapter of life and become the true adult he already was but still, it doesn't seem real until it actually occurs. We have been planning, saving, watching and listening to his plans and ideas and talking about this for some time now. Where was he going, what was he going to major in, where was he going to live and all the regular stuff. We listened more than advised and let him work out what he thought was best for the most part. Some ideas grew, others faded away, and a plan fell in place.

Sure, as a parent it's exciting to see your children turn into what you've been working, hoping and praying for the last 18 plus years or more. This is what you've wanted all along is an independent, kind, smart, generous human being that will be a positive part of this huge world. So it's done for the most part now... Sure we will be listening, advising and talking still, hopefully forever, but once they leave the safety of your home, their bedroom, it's amazing how bittersweet it can feel.

I was so sure I'd be fine with it, I'd be proud seeing him move on and take on the world.. and I am. But I'm also surprised how sad it really feels knowing this is a BIG change in OUR lives as well as his. To know he won't be home every night and I won't be waking up at 2AM to make sure the Home Automation told me the garage door opened after I went to sleep and Austin was indeed home safe and sound. Knowing he is pretty much on his own with 18,000+ other students at Oklahoma University that are creating their futures as well.

So now it's on to the college years, on to OU, on to meeting new people, making new friends and learning not just academics but how to be successful, happy and productive for the long haul.

I guess like anything it's hard letting go, but go he must hopefully always knowing he is welcome home anytime, can call, text or write and can fully expect us to be "checking in" with him more likely more often than he even desires.

Love you Austin and best wishes for your new world!
Dad

PuP - Pretty Useless Playtoy

PuP - Pretty Useless Playtoy

PuP is just a hack of an old toy that was getting thrown away. Honestly the factory function was likely as entertaining as he is now as it would bark, bark, and drive forward and backwards… but only over and over again. Now he can “see” what’s around him and respond in a couple different manners. Still only forward and backwards but he does move at least.

Original Plans / New Plans

Originally my thoughts were pretty grand for such a small little thing. I wanted a Pro-Mini, LiPo battery, sonar, sound, IR receiver, LDRs, a wagging tail, servo head, RGB mouth, a piece of metal on top of his head using touch sensing for petting, and more. BUT the reality of getting just the CPU and battery inside the small ½ section of the body stopped those plans. I had even thought about using a “leash” to power him to remove battery needs and make more room for CPU, etc but wasn’t sure how well that would have worked out.

I still really wanted PuP to move forward and backwards, talk, and have a sonar for eyes though. So after some success with an ATTiny85 on Buford and Buzz I figured that may work for PuP. So the plan was scaled back to ATTiny85, sonar, speaker, RGB LED, and home brew transistor H-Bridge.

PuP Build

Pup was decapitated, man that sounds harsh but that’s what happened, and a 9g servo replaced his head after some “plastic surgery”.  Once mounted up a couple face options came to mine but the easiest route was taken. Servo horn, 4 pin header mount, piece of metal across the top and some brown printer paper for ears worked for me. I found another small speaker, glued it up in between the sonar “eyes” and then thought about what to do for light output, tongue or something..

By now I was already running out of pins with the 5 pin limit for an ATTiny85. I already had 1) Forward drive, 2) Reverse drive, 3) Single Pin Sonar, 4) Speaker Output, and 5) Head servo… Actually I was already OUT of pins but I wanted PuP so have some light of some sort!

So the first thing I tried was paralleling the Red of the RGB with the speaker output. That works but you can barely see it as the output is pulsed and the speaker takes most of the current. Next I hooked the green and blue up across the forward and backwards output pins. Since the pins go HIGH to make him move and the RGB LED has a common POSITIVE lead, the Blue and Green stay ON while sitting still and go off depending on if PuP is moving forward or backwards. Works at least and gives a little light show.

Making It Fit

Getting it all to fit was still a challenge, even with the ATTiny85. I had to make sure I could get to the ATTiny85 to pull it to reprogram it the million or so times it takes me to get code right. Plus I had to fit the battery and the tiny Pololu 5v step up/down regulator in to make sure the sonar would run at 5v properly. It kind of worked, I really should have put the regulator on top of the battery and the ATTiny board in the rear but too late at that point. I had to do some more plastic surgery to get the top half to mount properly and now PuP has his “brain” sticking out of his back a little but hey, he’s just a PuP.

Fitting things on the head wasn’t quite as complicated. I needed to get signals power to the sonar, LED and speaker and signals back for each as well. I ended up tapping of the power and ground on the sonar and then added a couple more female headers for the speaker and LED. I actually have an extra wire running from head to body now but do not see anything to use it for.

Unique Walk

The unique thing about PuP is how he “walks”. There is only ONE motor deep inside his guts. It drives some gears that then drive the balls on his feet which are splayed out. As the balls turn together one direction, he moves forward, the other direction, in reverse. Looks nice and functions pretty good actually.

One thing I did NOT realize until he was completed was the right front leg not turning when he backs up is apparently a “feature” I was unaware of. I thought there was a problem or broken issues with him until I watched it a couple times in action. This allows PuP to move reasonably straight forward but to turn by backing up to the right. Like some real cheap RC cars you see that only have forward / reverse but turn when backing up.

This is something I really need to take advantage of when I further develop the code for him to allow him to roam around a bit more.

PuB - Pretty useless Brain

PuPs brain is pretty simply, but has room to grow if I want it to since it’s only about ½ full at this time. Right now he starts out just sitting there staring out to the world. If you get close enough he’ll lock onto you hand and try to follow you, if you move too close though he’ll back up, and if you get super close he starts to get worried, his voice goes up in pitch, and he turns his head away and continues to back up. Get even closer and he turns his head the other direction like “get away from me!”

The next step is to add some more modes to him such as roaming while looking around and just avoiding things. Trick here is there is no easy way to swap modes as I am out of input pins so I will likely use my old tick like on Chomper and others of getting in his face as a mode changing option.

Obviously some random features of just getting bored, looking around, making some sounds etc if not stimulated for awhile need to be added as well. Just makes it a bit more enjoyable to mess with.

Closing - Good Results from Bad Code

MaxHires and I were chatting in the shoutbox about “unintended good results of bad code”. Max said he has had that happen in the Apple coding days with graphics where code  errors can generate some awesome artistic results.

PuP has a very simple example of this in my opinion. I am using the SoftwareServo library in PuP. It works but is a little different in that it requires you to constantly call the SoftwareServo:Refresh routine to keep the servo moving and in place. Since I am not using a library to read the sonar on one pin, I have to go read sonar and wait a bit so the refresh doesn’t always happen as quickly as it needs to.

One result of this is that sometimes, if PuPs head is turned away 90 degrees, he doesn’t just snap it back to front and center when he’s done hiding, he kind of bumps it a couple times when the refresh hits. Which is actually more “natural” than speeding back to center. This results without any intentional coding on my part. Heck if I TRIED to do it, it would likely not work at all.

My TED robot has a similar effect in that in some instances he seems alarmed and jerks back when he sees something while walking. Reality is I’m not handling the object detection cleanly and am jumping to different servos positions but it still “works” well.

So go build, go code, and sometimes, leave the bugs in… may make it a bit more fun!

Stephen

Sir RoBert the Robot

Having built TED the BiPed ( and NED, a 5 servo design I've never posted) and having watched the BoB revolution, and up until recently not having a 3D printer, I left the BoBs for others to build. Recently I decided to go ahead and print a BoB as the printer seemed to be working well with Jinx and other LMRians help. Once printed I was even considering giving it away to someone that wanted to build one. But then someone posted a link to a little bot (http://learn.adafruit.com/trinket-powered-rover) that had the STL files for a silly mustache that clips to an ultrasonic sensor.

---

I looked at the empty BoB shell and thought I have to see what a ‘stache looks like on him. I made a quick print of the mustache and stuck it up there and actually LOL’d. Someone else in the SB said he needed a tophat so a quick search turned up one, a not so quick print yielded a nice little hat for the BoB and he looked quite official. K120189, the BoB GoD and creator thereof, donned him “Robert” so that must be his name.

 Just a note: Unlike most of my bot posts, this one really isn’t very close to “done”. Still a bit of coding I want to do once the platform is stable. Also want to add some more sensors such as light and sound and play a bit more with making him entertaining. But with the core done figured I’d post him up. Will update as new things are added to him.

 

Sir RoBert Brains and Senses

With Sir RoBert destined to be built, I began planning the layout, functions, etc. My obvious choice of a BoB Brain was a ProMini clone which I still love working with and am getting quite familiar with. Add the under $5 US price tag for a 328 CPU and it’s hard to beat in my opinion. Sir RoBert is fitted out with a normal ultrasonic sensor but it’s a bit more of a challenge to implement other sensors on this platform.

The normal ultrasonic sensor is obvious and useful for object avoidance but getting anything else like light dependent resistors (LDRs) etc mounted somewhere is a challenge. Additionally I really like having an infrared (IR) input on my builds to allow switching the “robotmode” variable for different features like roam, light follow, attack, wag, RC, etc. BUT I also want the build to look as appealing as possible. For the IR sensor I kept sticking it on different places around the BoB head and nothing really looked right until I stuck it above the mustache like a nose. Perfect fit in my opinion and that is where it stuck.

Getting light sensing on a BoB is a little trickier. It’s also not overly useful under my standard code on a biped that is twisting around back and forth all the time creating odd lighting patterns, but I still wanted to have the left/right light sensor features. I picked up some Radio Shack 3mm Ambient Light Sensors http://www.radioshack.com/product/index.jsp?productId=22472186 and will put them in the outer LED mouth holes for some type of light sensing. He at least needs to know which side of his face is brighter / darker and can respond. The key for sensing while moving is to only sense when his head is flat / forward which can be accomplished by a variable that is updated through the walk cycles. It could also be done with an accelerometer / Gyro / IMU solution but seems overly complicated for my needs. I haven’t added the light sensors yet but will be doing so in the near future.

Plug and Play

I really never realized how small the BoB head is until trying to get things stuffed into the head instead of on the outside. I really wanted everything in his head but still wanted and needed to be able to get to his brain and “inside his head” when needed. After thinking about long wires to do it, I looked a bit closer and it seemed like a set of female/mail headers would make a “plug and play” BoB head. I used two 90 degree male header pins on the bottom glued to the tops of the hip servos and glued the matching female headers on the inside sides of the head. To help line things up when putting the head on the base I added a couple pins that line up with the screw holes on the sides of the head.

It is now pretty easy to pull the head off, add stuff, fix stuff, etc and put him back together without a rats nest… well, too much of a rats nest at least, of wires, confusing connections, etc. Not perfect but pretty handy so far.

Pin In/Outs

Connected to head

2

3  

4  Sonar In/Out (Using single pin mode)

5  Ch1 Input

6  Ch2 Input

Not Connected to Head headers

7  

8  Right Ankle

9  Right Hip

10  Left Hip

11  Left Ankle

12  Red LED

Connected to Head

13  Speaker

A0  IR Input

A1  (Future Left Eye/Light)

A3  (Future Right Eye/Light)

A4

Not Connected to Head

A4 Green LED

A5 Blue LED

A6

A7

 Remote Robert

 Thinking one evening (yeah, scary thing, I know) I thought it would be cool to be able to radio control Sir RoBert with an regular radio control car controller that I had laying around. Only a two channel so some challenges but seems it could be done. My original thought was purely a free form, Arduino in the middle, solution where RC wheel input leans left and right and throttle moves right leg / left legs in a walking pattern.  

This works pretty good to me allow the steering wheel to rock Sir RoBert left and right and the throttle to move his hips back and forth. Walking is a bit of a challenge to get it coordinated but with this free form way of controlling him he can get pretty crazy acting bouncing back and forth and shuffling his hips. Rocking for a formal old man.

That will work and is still a cool way to play with the bot making him move from foot to foot and shuffle or walk around. After Input from K120189 in the SB made enlightened me to the point that the radio control could also be used to trigger the “drivemode” settings I use. I.e. throttle back and he walks forward on the standard routine, reverse backs up, right turns right, combo walks and turns. So you can really just “drive” Robert around.. albeit not very fast.

Expanding on above, I have a “drivemode” variable in my code for most all my robots. That determines for each loop if the robot is just stopped, going forward, backwards, turning in place, turning gradually, etc. That way any input can subsume another for obstacle avoidance, etc. In the RC “robotmode” case, the loop simple reads the radio receiver input and sets the mode or drives the servos in a new mode for direct access. Simple but works for me.

Filling the Head

So with that wonderful plan in mind I built up the robot putting an old 75mhz RC receiver I had laying around in the very top of his head and then piled everything else in on top of that. Getting all the wiring lined out right is a challenge in such a small place but it all seemed to work out. The biggest challenge is getting power and ground runs to all the sensors, header, speaker, etc so I piggy backed the nose IR sensor off the Ultrasonic sensor which saved on connection pair. I then used the two channel connectors to the RC radio only running power in one and ground in the other removing an additional connection there.

I found a tiny charger jack and power supply from an old cell phone and worked it into the back of the head, dropped in a small SPDT switch to turn him on / put in charge mode, and messed with a single RGB LED for some type of light. He really needs a bunch of 3mm LEDs but I didn’t have them so the RGB setup has to do for now.

At first I thought it would be really cool to embed a USB/TTL adapter into RoBert to allow any USB connection for programming, etc. I filled up the square hole in the back with one, set it all up and then realized I needed a USB extender cable to hook him up to the computer. Next I found that every time I plugged RoBert into the computer I had to wait for the USB to be found, re-select it sometimes, etc to program. With my lousy programming skills and the 1,000 times it takes debug/fix/re-upload my code that wasn’t going to work. I resolved it by removing the USB adapter and just extending the standard +5v/Gnd/Xmt/Rcv pin headers on the ProMini. Much easier and I can keep the same serial port for programming nearly all my bots. I did have to add an external reset button since I do not use the auto-reset wiring scheme but easy to do.

With everything installed I loaded up my standard TED code, tweaked a few servo end limits and let him try to get around. Does ok actually but still needs some limit adjustments as he will fall over pretty easily. But working so next I thought I’d try free form radio control.

Remote Gone Wrong

I added another “rcrawmode” robot mode and added the code to read the receiver controls thinking it would be pretty easy. Initially I was just powering him off the USB connection and the RC stuff worked fine. So I unplugged him, turned him on and selected RC mode with the IR remote… and he went into spasms… twisting and turning and going stupid silly. Hmm.. ok, what is going on. First I thought maybe a library was conflicting while I was reading pulse in but it worked while tethered? It finally dawned on me while looking into the head that the old 75mhz radio was mounted right next to the little Pololu 5v step up/down regulators that I use. I really figured that was it so I bypassed the regulator and powered things up from a different pack. No problems like that. Great, so my old timey radio isn’t going to work.

Next step, move to 2.4g setup. I already had an extra 2.4g receiver from my RC Truck racing days and a transmitter that could drive it so now I had to dig the old receiver from it’s mounting point underneath EVERYTHING else in the head. Only broke ONE wire doing it… surprised. Next I squeezed the new receiver in, wired it all back up and it worked!

Future Work

Sir RoBert needs some time spend on code to get him balanced out but otherwise he should be able to roam, avoid to a degree, dance with RC, play a few songs, and do the hokey pokey like most of my other bots. It’s all there, it’s just a matter of tuning settings for this particular platform but what I like about Sir RoBert is that he doesn’t look like a “robot” thrown together with scrap parts, he actually looks like a little toy guy.

Unintended Results

MaxHires and I talked a bit in the shoutbox about how bad code creates good, or at least interesting results and Sir RoBert does have some of that. There is still some issue with conflicting libraries, timers, or interrupts so the servos have the “jitters”.. BUT since Sir Robert is supposed to be old I’m just passing it off as being an “old man”.

Buford Highwater Micro Robot

Buford Highwater

Yeah, that is a silly name for a big bad “Robot” but for some reason it just hit me while trying to piece him together and he’s a tiny fellow anyhow. Buford was really an afterthought when I finished Lilliputian. I had started the original Yahmez MicRObot challengeentry with the concept of a dual ATTiny85 bot, one for brain, other for motors but gave up and used a ProMini clone instead. After looking at the left over parts for a bit I thought surely I can throw something together with these. Besides I had yet to build any actual robot with one of the ATTiny85’s I’ve had for a while.

Update 01/04/2014 - Added Schematic at the Bottom

Buford’s Pants

Buford’s pants are a 3d printed mount found on Thingiverse. I found the part some time ago but never really had a good plan for it. The GM15 gear motors are actually too small for the mount and I didn’t really want to burn time modifying the part so I wrapped them up in some green electrical tape. Once the pants were done I thought a 3.7v 240mah LiPo battery might make a good “backbone” so the hot glue gun came out and he was now upright.

Buford is a pretty minimalistic bot featuring the two GM15 gear head motors mounted in the “pants”, the battery forming the backbone and some small 3D printed “third legs” to hold him up. The wheels are Lego gears and the tires were from Lego as well I believe or maybe somewhere else. For driving the motors a couple 2N2222 transistors were used which allow only forward motion for each side. Seemed the only way to keep things small enough for the platform and is very easy to do.

Buford’s Head

With the 8 pin socket for the ATTiny85 in the middle I sketched out a layout to allow two LDR’s for eyes, a couple transistors to drive the motors, matched up the needed resistors for the LDRs and transistors and then mounted an IR sensors below for his mouth like feature. After digging around for ATTiny85 IR code online and thinking about how Buford was going to be a mute with no sound output as there were no more I/O pins, I decided to change out the IR receiver and put a tiny speaker I had salvaged from an old cell phone. The tiny square speaker mount fits nicely below the Tiny chip and although not loud, provides enough noise to make him a little more menacing… I mean annoying.

The back side of the board is a little messy, especially considering I took the time to draw up and layout the whole wiring scheme, followed it exactly and THEN realized I designed the LDR’s with the resistors going to the input pins instead of to ground. “Face palm” time. That error made me go back, cut up / out some of the wiring and get it right the second try.

To spice up his head I added a couple green LEDs in parallel to his drive motors on the back of the board which glow depending on how hard that motor is being driven. Because the GM15’s are pretty high geared and the wheels/tires are pretty large he is way too fast for his own good so the PWM rate is extremely low and hard to control but he does move at least.

To get power to the board I thought about a few options but did not have a tiny double throw on/off switch that would allow charging the battery in OFF mode so I just added a two pin header, extended it a bit to make it look like “hair” and added a connector to the battery wires. Kind of looks like a pony tail from the back.

I tried to make his board have some resemblance of a “face” with the two LDR’s up top for eyes, the 8 pin CPU for a nose and the speaker for his mouth. No clue what the resistors are, warts maybe. The two transistor kind of stick out there. I had thought about maybe some tiny hands but he looks good enough to me for now.

Buford’s Brain

There’s not much there to start with but he does have 8K of empty space to fill so he can do a few things. He should be able to 1) Track Light; i.e. sit still and rotate to face the brightest until he is balance, 2) Hide from Light; same thing but avoid light, 3)Follow Light; move towards the brightest light until close enough, 4) Run from Light; turn away from the light and keep moving until dark enough.

I started to code up some options for selecting modes by covering up the LDRs, you can pretty easily do three different settings by fully covering up the 1) Left, 2) Right or 3) Both for three options. BUT then I really thought about how easy it is to swap out the ATTiny85 and how many of them I had here so I just changed variables and burned a chip for each mode. I can then swap them out as desired. Not optimal solution but quick and dirty way of making it happend.

So far Buford can track light and follow it in a kludgy but walking like wobble which I actually kind of like and turn away and run away from light. Nothing special for sure. There is still plenty of code space left with the current code taking about 3K of the 8K available. Unfortunately the speaker output is not very loud so trying to make much sound isn’t near as noticeable as I’d hoped. Additionally I guess the ATTiny85 doesn’t support the Tone() function to play musical notes so something else would have to be done to play any type of “music”, if you can call it that.

Parts List

To summarize what makes up Buford here is the summary of the parts list:

2 x GM15 motors

2 x Lego “Gears”

2 x Rubber tires off something

1 x 3d Printed “pants”

3 x 3d Printed rear supports (only two needed but I tried a tripod setup that didn’t work)

1 x 3.7v lipo battery

1 x 1” circular perf board

1 x 8 pin ic socket

1 x ATTiny85 (or more if you want to program up various modes)

2 x 10k resistors for LDR

2 x LDR devices

2 x 2N2222 transistors

2 x 1K resistors for transistors

2 x bright green LEDs

1 x cell phone speaker

2x 2 pin 90 degree header pins

1x 2 position female pins and header

1x pull your hair out soldering session on the back to make it work

Wow, ok, there are a lot more parts there than I thought but it’s still pretty simple

Closing

So there is Buford Highwater. Only took about 8 hours on and off total messing with ideas, code, etc to put it all together. I obviously reused code from my other bots for the base code, just stripped out all the other libraries and music functions that were not needed.

So he’s Buford, he’s bad, and he’s big… well, no, he’s actually tiny… ATTiny too but he’s still a menace.

Stay out of trouble Buford!

Update 01/04/2014 - Schematic

Maxhires has asked about the schematic and driving the motors etc from the ATTiny85 so here's how I did it. I'm sure there are btter ways out there but this does work. Notice I am driving the little speaker directly from a pin. I've done this for all my bots with sound without issues but remember these are tiny speakers so I would guess lower current.

Lilliputian Micro Robot

Lil·li·pu·tian

n.

A very small person or being.

adj.

1. Very small; diminutive.

2. Trivial; petty.

Updated 01/02/2014 - Added in progress pics at bottom

Lilliputian - seems like a pretty good description of this little fellow. Trivial, petty, diminutive, very small, etc. With all due respect to Swift’s Gulliver’s Travels of course. Inspired by Yahmez MicRObot challenge, this is my 2.0 attempt. The first attempt is still there and maybe viable for a future finish but I like this 2.0 layout much better. I just packed in as much as I could WITHOUT resorting to surface mount devices (SMD) which I have no skills with.

 

Size Matters

 

At least in the challenge so first I guess I should outline the current size of Lilliputian. Currently the bot is about 35mm wide by 50mm long (not including the bumper horns) and 35mm tall. Total weight is 34 grams (1.2 oz). Not tiny by any means or as compared to some other entries I guess but small for me. I gave up some size for features which was the plan from the beginning.

 

Chassis and Motors

 

Lilliputian features a 3D printed base chassis of my own simple design to mount the two GM15 micro motors. To keep things narrow I offset the motors and wheels giving it a bit of a goofy stance but making it much narrower than traditional back to back mounting. That is where some 90 degree gear motors such as those recently sourced by Yahmez would be quite handy. For wheels, I used a couple old mouse wheels that I had kept. It took a bit of work to clean out the middle to allow mounting and they are definitely crooked and poorly mounted but they have stayed on so far.

 

For speed control a L293D chip was used and was soldered up “dead bug” style. Without an inverter it does eat up six output pins to control the two motors but I figured I had plenty of pins in this situation. Two pins are used to control motor direction for each side and a pin is then used to drive PWM for each side.

 

However, the GM15 motors are really geared a LOT higher than I thought there were and the tall mouse wheels really push the speed of the bot beyond usable levels. The balance between enough PWM to move and too much while cruising is a challenge. Some better coding would be helpful as Yahmez suggested to maybe ramp up the power to get rolling and then settling it down for cruising speed. Something to work on later I guess.

 

I designed the chassis to use basic Pololu QTR encoders with striped disk on the wheels. I’ve done this before with larger sensors but not this small. I thought the Pololu QTR-RC sensors would work as they are small and since I didn’t read the datasheet like a fool I put the thing together and could not get output from the sensor. More reading revealed that you need to use the library to read the sensor as what makes them digital is the small cap that must be charged and then read using the same I/O pin. That will NOT work with driving an interrupt pin for encoder reading. I even tried making my own timer interrupt routine to go read the sensors but could not get any consistent output. Since then I have purchased the QTR-A sensors which are pure analog but have not tested if they can transition enough to drive a digital interrupt pin. Plus the fact that the wheels are glued to the output shafts and the wiring is on the opposite side there is no clean way to replace the existing encoders so that part of the bot is on hold.

 

Power

 

Powerwise a 3.7v lipo with onboard electronics for under / over voltage protection was mounted on the bottom side. It’s easy to get to and replace in case it bloats from overcharging and tucked up underneath quite nicely. However, everything on the bot is 5v so I used a Pololu step up / down regulator to turn the 3.xV into 5V. I believe the current limits are 500ma but it appears to be fine for my needs. Pretty sure I could not have run a ping sensor along with everything off that current but this thing is too small for such a sensor anyhow. I couldn’t find a switch that was small enough in my junk pile so I just used a three pin header for power and changing needs. I use a header jumper to power it up and a three pin connector for the charger. I used a wall wart charger that came with a little quad rotor and it appears to have some current limiting in it as well and has charged the battery without issues. The battery is a 240mah LiPo version but driving the speaker appears to really eat up power so run time is not impressive. Fun, just not impressive.

 

Brain Power

 

Originally I really thought I would go with one or more ATiny85 CPUs for this build but seeing the ability to mount up a ProMini 328 I changed direction as it is still my favorite Arduino CPU to use since it’s so small with full 328 capabilities and memory all in a 24 pin DIP. Instead of building a undershield or perfboard this time, I simply glued the CPU to another little mount I designed and printed that also mounted the wheel encoders (that do not work as noted above). I then soldered wires directly to the CPU instead of using header pins. Messy but seems best at this scale for me.

 

Sensors and Stuff

 

IR Receiver

I added an IR receiver to allow controlling the bot and his “modes” with a standard remote control. Each mode can be selected from the remote including RC control, autonomous mode, and some special entertainment type of functions. The IR sensor mounted on top of the AtMega chip on the ProMini quite nicely in my opinion. For now I’ve used an existing remote from a Toshiba stand alone DVD burner I had in the workspace but any remote could be used as it is quite easy to add IR control to a bot. I used to think that would be a challenge but with the IR library it’s very simple.

 

The remote is primarily used to change the “modes” of the robot from roam, light seek/avoid, light track/hide, “wag”, bark/attack, line follow, etc. It can also be used to drive the robot around with the arrow and navi buttons if desired.

 

IR Transmitter

Since I could not get the encoders to work, that freed up pin 3 that is used for the IR transmitter library so I stuck an IR emitter on the right rear of the bot. Thoughts are he can eventually communicate with SBot or something like that. Nothing is coded yet but maybe later.

 

LDR Light Sensors

Sensors are rather simple with two LDR’s for light measurements. Good news is the LDRs work well. Lilliputian can sit still and track light, turn away from light, and follow or run away from light. He also makes little bleepy sounds when he’s not happy with the light balance as he sees it. Bad news is my light follow code isn’t overly developed so he can get confused and start spinning in place rather easily.

 

QTR-RC Line Sensors

The line sensors do seem to work well using the Pololu library and can easily detect light, dark, and edges. BUT doing so in a fast enough manner to get a timely response from the platform has been a bit of a challenge so far. Additionally my chassis design leaves some to be desired as the offset wheels make it quite easy for the bot to do a “wheelie” when taking off which confuses the front mounted line sensors into thinking it has seen an edge so it stops, backs up, takes off and repeats the loop. Not good. I ended up mounting a small piece of Lego jewel in the back corner to stop the wheelies helping the edge detectors to function.

 

Bump Sensors 

Without sonar Lilliputian is pretty blind so I added a small bump switch up front. I can’t remember where these little switches were scavenged from but they are pretty handy little things that take very little pressure to turn on making them good sensors for a small bot. I think they were out of some old tape backup drives or something. Without whiskers they are pretty limited but does give some sensing to back off, turn and continue on at least.

 

Light and Sound

I always like my bots to make a bit of light and noise since I’m easily bored so a piezo speaker was salvaged from an old PC motherboard as recommended in the shoutbox and mounted on the rear. A cycling multi-color LED was mounted up front that adds a LOT of colorful light, in fact a bit too much so I added code to turn it on/off via the remote control. With the little speaker Lilliputian can play a few songs and act out or dance a bit.

 

Feature Set

 

Lilliputian currently has the following modes and features:

 

Roam mode 

Not overly useful but wanders around bouncing off things, avoids black lines if the line/edge avoid flag is set. Line/edge can be turned on/off with the remote as needed.

 

Light Track mode

In light track mode Lilliputian sits still and turns toward the brightest light source he can see at the time. If it’s too bright or you get too close to him with a flashlight he will back away from the bright light making a little noise. Again, in this mode he doesn’t drive anywhere forward for light, just sits there.

 

Light Hide mode

Just the normal inverted light seek mode but again sitting still and turn away from any light source until he is happily balanced. This really doesn’t mean find the darkest point, just turn away from any brighter light source.

 

Light Seek mode 

In light seek mode, Lilliputian follow the brightest light using the front LDRs for balancing. This works best when pointing a flashlight at the front allowing light control of Lilliputian. He will follow the brightest source he sees and once things are bright enough he will stop. If you make things too bright he will back away from the light.

 

Light Avoid mode

Again standard light avoidance routines, run away from the light. In this mode if he finds a dark enough situation he will stop as well and wait for any light changes.

 

Race mode

Just a silly little setup where he counts down with blips and takes off at full speed for a second or two. Just like in real racing, sometimes he crashes trying to go too fast. Once done he sings a little tune and spins in place having enjoyed the thrill.

 

Wag mode

Another silly one borrowed from SBot. Just wags back and forth for you.

 

Bark / Attack mode

Another silly little routine from SBot where he drives forward, makes a barking/noise sound and retreats.

 

Line Following mode

Lilliputian is really not well versed in line following yet. He can “usually” follow the line but with the high speed, bad code, and having to check for IR inputs, etc he can easily miss the line and take off running away. Even when following the line he is pretty jerky bouncing around trying to stay on course. But he can make it around a normal line sometimes.

 

HokeyPokey mode

 

Apparently he learned this routine from my TED robot I guess. One of the most important routines he plays the song and does the moves the best he can. Seems like he is having fun at least.

 
 

Future Feature Set

 

Maze solving - Really want to have it run the maze, store path, and re-run it… someday

Things that Didn’t Work

Wheel Encoders

Obviously the wheel encoder setup didn’t work as mentioned above. This may be resolved

through a different encoder but that will have to be for another bot someday.

 

Onboard Compass

Originally I really wanted to drop a small HMC5883L compass module I had on the bot. I tested the module on the bench and it worked pretty well. however, mounting it up on Lilliputian proved to kill the usefulness of it as mounted down by the CPU the compass does not work apparently from the RF interference of the CPU or maybe the magnets of the motors underneath it. I have built a small stand off to allow the compass to work but not really crazy about how it looks so not included here.

 

Closing Summary

 

So big plans scaled down for the most part. Original goal was wheel encoders, dead reckoning navigation, compass directional controls, Light sensors, line following, maze solving, IR controller, little monster. Reality is a neat little platform but not all the bells and whistles I originally had desired.

Oh well, one can’t hope for too much out of a Lilliputian unless there are a lot of them right?

No, I’m not building a lot of these things - too small for my patience :-)

Update 01/02/2014 - Added some early Pics

Per Lumi's request, here are a few early on pics. Unfortuately I didn't take many in process pics like I should have.

Raw printed chassis that I designed. Very simply base platform and two tubes to hold the motors.

Chassis loaded up with the GM15 motors and mouse wheels/tires.

Mounting the CPU up top. You can't see the mount which is just a tube with a flat piece on top to mount CPU.

Top view before CPU mount. The step up regulator on the left, H-bridge dead but up front.

Initially I was going to try using an LED and a couple LDRs for line follow. Bought sensor instead.

This is the best view I have of the "guts". Before line sensor install but you can see the wheel encoder attempt.

Pretty packed in but generally functional. I still think the right encoders would work.

Wouldn't be high resolution but could be useful.

Thanks for all the comments and encouragement all!