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!