Older blog entries for shimniok (starting at number 120)

Making Slot Car Tires

As Christmas approached when I was a kid and Rudolph the Red Nosed Reindeer aired on the TV, Dad would return from the garage with an enormous box emblazoned with "Thunderbolt III" and a picture of two race cars battling to victory.

We set up the Strombecker slot car tracks and, grasping the blue speed controllers, we brought to life the epic struggle of white Chaparral 2D and yellow Ford GT 40 Mk II, father versus son.

I still have that old slot car set. And now a child of my own. And though Dad left this life in 2010 and mom passed away in September, they'd be happy to see my 7 year old daughter and I reliving those moments from my own childhood.

Except... when I finally unwrapped the cars, stored carefully 35 years ago, the tires fell apart in my hands. Rats.

After some online research, I discovered one can create custom slot car tires using a 2-part RTV silicone rubber. So that's what I did.
I found an Alumilite Super Casting Kit for $40 with coupon from the local craft store. The kit contains 2-part silicone rubber, 2-part resin, mold release, measuring cups, and stir sticks.

The instructions describe using the silicone rubber to make the mold. Instead, I made a plastic mold with my Monoprice Architect 3D printer and used the rubber, instead of the 2-part resin, as the casting material.

I designed the mold in FreeCAD. It is designed to mold the tires right around the original tires. The mold is basically just a bowl with a raised cylinder that the original tires snap onto. Then you pour the RTV Silicone goo around the outside of the wheels.

Transparent 3d view of the mold

In the first attempt, I thought it'd be fun to add black coloring. Since the silicone is white, the tire came out dark grey. I'll have to look for some clear silicone in the future.

The first two test tires came out fine, and I put them on the GT40. I replaced the rear axle and tires with a set from eBay.

I had a working slot car, although the silicone tires were slightly too large in diameter and inhibited contact of the pickup brushes with the track.

For the Chaparral, I printed smaller front tire molds, and then printed the rear tire molds. I was able to get measurements from the crusty original tires before they fell apart.

The next day I had a set of white tires for the Chaparral. However, they have a tendency to come off the wheels really easily. But, they do have more traction than the original rubber.

For the next attempt I'll 3D print a wheel and mold to create undersized tires that have to stretch a little to fit onto the original wheels.

I ended up going a little nuts over the last month, buying two more cars (both need rear tires), a New Old Stock chassis, new brushes, and a ton of track. I repaired a lot of soldering issues on the cars and track.

We've had some good fun racing with family and friends. But I have more up my sleeve. I'm working on a track timer...

Syndicated 2016-12-27 00:00:00 (Updated 2016-12-27 00:00:03) from Michael Shimniok

24 Dec 2016 (updated 26 Dec 2016 at 22:11 UTC) »

Hello LED

My wife and daughter adore Hello Kitty. No, I mean really, really adore her. No, see, I don't think you quite understand. Here, let me just show you what Christmas looks like at the Bot Thoughts laboratory:
This Christmas we faced a major problem that would totally ruin our holiday season.

At night, the smallest of the inflatable Hello Kitties were really dim! And the lights inside them were --gasp-- not user replaceable!

Before: Small kitties are dim!
Well, we are not users, are we, gentle reader? With a little knowledge of electronics, we can fix the "unfixable". Here's how things looked with only 3 kitties left to fix.

All but three kitties have been upgraded
So, here's how we brightened up our Christmas Kitties...

What We're Dealing With

There's a single, white, surface mount LED inside the small kitties at the back of the head, clipped to the material from the outside (see right)

These inflatables have zippers at the bottom to access the internals. There's no need to unclip the LED.

The medium sided kitties have two LEDs. So, maximum of probably 20mA per LED.

How much voltage and current do the small power supplies provide? Voltage, verified by my multimeter, is 12V. Current available is 1A.
Epoxy-encapsulated single SMT LED


We settled on two sets of four series-connected LEDs and a series 82 ohm resistor. So, four LEDs in parallel with four LEDs.

Make sure you use a resistor rated for the power through it. Power is given by current times voltage: P=IV. So for example, 10mA x 12V = 0.12 watts. That's nearly 1/8W so I used 1/4W and 1/2W resistors I had laying around.

I selected wide-angle, 20mA, high brightness LEDs from Digikey, (Part No: C535A-WJN-CU0W0231-ND)


I found some great protoboards on ebay. Long and narrow, it was easy to install the LEDs and resistors.

Since my wife has mastered soldering while teaching the 5th graders, assembly was a team effort.


Installing the LED array was a matter of unzipping the un-inflated Kitty, reaching up in and grabbing the LED module, pulling out to access it.

Then, clipping the wires, I soldered them onto the protoboard.

I placed a dollop of Goop to glue the new board onto the old module.

Then added a zip tie (pink of course), belt-and-suspenders style, and we have bright kitties again!

Merry Christmas and/or Happy Holidays!

Oh, Here's an LED Refresher

These white LEDs have a forward voltage drop of about 2.8V and a maximum current of 20mA. By reducing current through the LEDs with a resistor, and by placing the LEDs in series, the current demands on the power supply are minimized while extending LED life -- at the cost of a slight reduction in brightness.

Kirchoff's Voltage Law states that in a circuit, when you traverse a single path starting and ending at a given node, the net sum of voltages is 0. You have 12V supply, so the load drops 12V. 

If you place four LEDs in series, the sum of voltage drops is around 12V. What about current through each?

Well, Kirchoff's Current Law states that the sum of currents entering and leaving any node in a circuit is 0. That means the current through each LED and resistor connected in series is the same.

It also means that connecting four LEDs in parallel draws four times the current as four in series. That's why I put the LEDs in series.

Finally, Ohm's Law states that voltage is equal to resistance times current for a resistor (V=IR).

Using all those laws, you can define the current you want through the LEDs and solve for the resistance value you need.

In this case, if I want I=15mA, and each LED drops 2.8V, then using Kirchoff's Voltage law, I can solve for the voltage across the resistor:

Then using Ohm's Law I can solve for the resistance, R, that results in a 0.8V drop and 10mA of current.

Closest E24 (5% tolerance) resistor is 56 ohms, but it's a good idea to see what happens in the worst case.

Most voltage regulators are within 5% (12.6V). Now if the resistor is at the low end of the 5% tolerance range (53 ohm), you'd end up with 26mA which is too high for the LED.

If you recalculated R for the worst case voltage and worst case current (20mA), you'd compute R=70. With the next E24 resistor of 75 ohms, you'd have a reasonably safe margin.

You could also check the LED datasheet and see if there is a worst-case (lowest) voltage drop on the LEDs. If you really wanted to get fancy, you could design a current source circuit instead that would be a lot less sensitive to power supply voltage error. But that's another story for another day.

Syndicated 2016-12-24 20:03:00 (Updated 2016-12-26 19:01:22) from Michael Shimniok

DIY Vehicle Speed Sensor Buffer

Here's the riveting tale of how I created a Vehicle Speed Sensor (VSS) interface circuit for my Jeep Grand Wagoneer (yeah, that Jeep).

Jeep VSS
Speed sensors are used by cruise control systems and by fuel injection computers. Jeep used one for the former.

I wanted the sensor for the GM throttle body injection (TBI) system I retrofitted onto the Jeep's old AMC 360 c.i. V8.

Back when my Jeep was built, vehicle speedometers were driven by a flexible steel cable, the speedometer cable, connected by a tiny gear to the output shaft of the transmission.

Jeep, as with other vehicles of the era, split the speedo cable in half and stuck the VSS in between.

So, with insufficient hobby funds to buy an expensive, off-the-shelf Vehicle Speed Sensor/Buffer, but wanting to reap the benefits of a VSS, I created my own interface. Here's how it went down...

The VSS Signal

Made of a rotating coil and fixed magnet (or maybe vice versa), the voltage across the two output wires of the VSS is a sine wave. It puts out 8000 pulses per mile.

As one would hope, the VSS signal's frequency increases with speed. But testing revealed that the amplitude increases too: from less than 1Vpp below 10mph, to a peak of around 4Vpp above 50mph.

The data points were all I could reliably obtain using a cordless drill to run the thing. But it provided sufficient understanding to devise an interface circuit.

Speed (mph) Amplitude (Vpp)
10 0.6
15 1.0
25 3.6
62 4.0

What the ECM Wants

Unfortunately for me, the GM ECM expects to see 2000 pulses per mile. And it expects a nice square wave, compatible with 5V logic.

The former can be managed by a counter/divider or MCU. The latter is easily accomplished with a
comparator. But that's only if the original signal amplitude is large enough. It wasn't.

My interface circuit would have to amplify the VSS signal first, then convert it to square wave, and finally divide the frequency by 4. But that wasn't all...


Before I can amplify or really do anything at all, the VSS signal's DC offset needs to be kicked to the curb.

That way, when using a single-supply op amp, I can use a 1/2 VCC virtual ground (2.5V) and the amplified output will have a 2.5V DC offset that will work nicely with a comparator.

A series capacitor does this dirty deed dirt cheap. Um. Yeah. Anyway...


Below 10 mph, the VSS signal amplitude was too low to work with. A single-supply operational amplifier with a high gain ensures the output reaches the 0-5V rails at all but vehicle speeds below 2mph, which the ECM doesn't care about anyway.

Example of a sine wave clipping
At higher speeds and greater sensor signal amplitudes, the output signal maxes out near the rails, cutting off the peaks (see pic, right).

That's called clipping. For music amplification, clipping sucks. For this signal it doesn't matter since we want a square wave in the end anyway.

One problem. After building the amplifier circuit and testing a little, the oscilloscope revealed unpredictable voltage spikes when the VSS spun at extremely low speeds.


Those spikes, amplified into pulses, would trick downstream logic circuits into reporting a faster-than-actual speed.

Filtering seemed like a perfectly sensible thing to do, assuming the noise was above the maximum frequency of the VSS signal. I suspected it was.

So, what was this magical maximum frequency I designed to?

Figuring on a speed of under, say, 100mph (the Jeep can achieve this only when driving downhill with a subtantial tailwind), one computes the maximum frequency as a unit conversion from pulses per mile to pulses per second (Hz):

The target was a low pass filter with a corner frequency around 200Hz. The low pass filter is the same as the amplifier, but with a capacitor in parallel with the feedback resistor. Use the formula below to find C given the feedback resistor R:

That's all well and good, but why not be a little trickier than that?

Using a smaller capacitor than calculated, the amplifier frequency response have gain at lower frequencies where the input was low amplitude, and would roll off to attenuate the signal at higher frequencies when the signal reached its maximum, while further attenuating higher frequency noise.

If you wanted to get fancy, you could carefully measure more input signal data points of frequency vs. amplitude, determine the best low frequency gain and roll off to maintain signal amplitude to tighter tolerances. Or a filter with sharper roll off could be used if noise is a really big problem.

Sometimes, it doesn't pay to engineer the snot out of stuff. As far as I can tell from testing, as long as the output signal amplitude is over about 2Vp-p across its range of 2-100mph and the noise is somewhat attenuated, then it is good enough for me to get this done so I can work on related projects and get the Jeep through emissions.

I used a trial and error approach to set the corner frequency until I got a reasonable amplitude at the lower speeds without any noise. I ended up using a 0.1uF capacitor.

The frequency response of the circuit starts with a gain of around 30dB rolling off gradually to -40dB by 200Hz, according to LTSpice:

I also found that a 22-33uF series capacitor on the input worked better than lower values that I tried.

Notice in the schematic below that the + input is connected to a virtual ground of 2.5V, half VCC, in turn providing a 2.5V DC offset to the output signal.

Converting to Square Wave

While a comparator can convert a sine wave to a square wave, in the real world a noisy signal may bounce back and forth across the threshold, causing the comparator to trip when it shouldn't. To prevent this, you need hysteresis.

A normal comparator has one voltage threshold. By contrast, a Schmitt Trigger has two thresholds. The high threshold is for rising waveforms, and the low threshold is for falling waveforms. That way, once the signal rises above the high threshold, it has to fall all the way below the low threshold before the output signal changes. And vice versa.

Fun fact, you can use an operational amplifier to implement a Schmitt Trigger. So I was able to use one dual op amp IC to implement the filter/amplifier and the Schmitt Trigger.

By selecting 100k for all three resistors in the Schmitt Trigger circuit below, you wind up with a high threshold of 2/3 VCC and a low threshold of 1/3 VCC.

Dividing the Signal

Rather than using a logic divider or flip-flop, since I didn't have any on hand, I just used a cheap ATtiny25. It probably draws less current anyway. It's definitely more flexible.

A simple C program sets up the INT0 pin interrupt to trigger on the rising edge of the conditioned VSS square wave. By toggling the PB3 output pin within the INT0 pin interrupt service routine, and also toggling PB4 every other time the ISR is called, we get a divide-by-2 on PB3 and divide-by-4 on PB4.

Skipping every other interrupt for toggling PB4 is achieved by checking bit 0 of a simple count variable. If it's 1, toggle PB4. If I needed to conserve flash and/or execution time I guess this would be a good way, though probably not the most readable method.

How would you code this? Is there a better way?

The Result

I prototyped the design on a breadboard throughout the development of the circuit, testing it with the VSS I'd pulled from my Jeep.

Once the output signal seemed reasonable, I reinstalled the VSS and hooked up the breadboard in the Jeep and tested it out driving around. I didn't see any anomalous behavior. Then I hooked up TunerPro to my ECM to display the speed as seen by the ECM.

My initial revision was a divide-by-2 circuit, so I quickly refactored the code to look as it does above, and voila, correct speed reading.

The next step was fabricating a prototype circuit board... but more on that in a future post...

Syndicated 2016-12-13 00:30:00 (Updated 2016-12-13 00:30:09) from Michael Shimniok

Teaching Programming to Kids (Cont'd)

After much struggle to select a microcontroller and programming system for teaching programming to my 5th grade club, everything suddenly came together.

In a flash I remembered PICAXE, which are low cost BASIC-programmable microcontrollers.

Even better, since all the kids have Chromebooks, PICAXE can be programmed with a Chrome App using the Google Blockly graphical programming framework.

For example, an LED blinky program looks like this:

As pointed out by my SHARC pals during a lunch discussion, 5th graders aren't expert typers so this kind of graphical block system sidesteps a lot of frustration. And I feel this system is better suited for robotics than native Scratch is.

The PICAXE Blockly IDE has some neat features.

First, the IDE includes a simulator so kids can run their code safely before trying it on the robots.

Second, they can see the BASIC language program by clicking a tab so they can get an introduction to standard programming languages.

My sample PICAXE-14M2 is now successfully blinking an LED on pin B.5. Soon I'll be prototyping motor control using the Pololu DRV8835 driver breakout boards I bought during the Black Friday sale.

And, I'm almost done designing a baseboard, similar to my PIPduino, that uses a Pololu step-up/step-down regulator (S10V4F5) for power, also a Black Friday purchase.

Since the PICAXE programmer cables are too costly for our budget I'm going to find or make cheap FTDI breakout boards or else put an FTDI and USB connector onboard.

It feels good to have finalized the MCU and programming system for the kids' robots. I'll order the baseboards soon and hopefully I won't have screwed up anything so we can get started programming in 2-3 weeks.

Syndicated 2016-11-29 01:00:00 from Michael Shimniok

24 Nov 2016 (updated 25 Nov 2016 at 17:07 UTC) »

Black Friday / Cyber Monday

Here's a list of sales you'll want to check out this Holiday:

Pololu Black Friday - already started! And an awesome sale with great deals once again. My order is placed :) Switching power supplies, robots (Zumo, 3pi, and the new Romi chassi); IR rangers from Sharp, Polou, and a time-of-flight breakout; wheels, motors, motor controllers, the cool A* ATmega32U4 controllers, and lots, lots more. Plus freebies and free(ish) shipping.

Sparkfun Black Friday / Cyber Monday - a wide range of items on sale this year. I'm eyeing the ESP8266 boards, MicroView, as well as the HackRF and RockBLOCK Iridium SatComm module. The FLiR Lepton board is on sale too.

BGMicro has a sale going right now, too. Take 10% off your ENTIRE order by using the code TTM at checkout through 11/23.

Parallax has a sale going too. Save $30 or more on:
Trossen robotics: 
We're taking 20% off RobotGeek and Interbotix products! Use coupon code "Friday16" at checkout.

Newark has tons of overstock stuff for sale

Syndicated 2016-11-24 04:02:00 (Updated 2016-11-25 16:35:20) from Michael Shimniok

On Teaching 5th Grade Programming

I know that 5th graders can code. 

The kids last year did a great job programming their Lego Mindstorm NXT robots in LabView, although I witnessed some confusion about the graphical representations. Perhaps Scratch, specifically Scratch 4 Arduino (S4A), might be an option. MiniBloq would be another possibility.

Still, I feel it will be easier for kids to learn a syntactically simple text-based language, like Python, Lua, BASIC, or SPIN. Why not C-syntax languages? I have witnessed too much time wasted on syntax problems--semicolons and braces--which I think distracts from core learning.

It is a bit of a quandary for me. What do you think?

Microcontroller Board

Low cost is a key factor. We'll have 5-7 teams, so anything that costs $25 or less would be affordable.

With DIP microcontrollers, we could use breadboards (adding slightly to cost) but kids may spend more time troubleshooting loose wires than solving the problem so I'd prefer to build a baseboard.

I am a huge fan of 3-pin servo-style connectors for my robots which greatly simplifies wiring, but non-reversable connectors would be better.

There's always the Raspberry Pi Zero at only $5. The cost is right but the kids may have to learn some basic Linux and we'd need a baseboard with serial or bluetooth. And honestly a Pi is way overpowered for what I have in mind.


Since learning Python, it feels like the BASIC of the new century. It's way more powerful, but simple to learn the basics, is wildly cross-platform portable, hugely popular, and much more. 

And of course I'm a big fan of MicroPython, which powers OpenMV Cam.

However, it is quite a challenge to find an suitable microcontroller board with a full MicroPython port that doesn't cost too much. PyBoard is over budget and requires a baseboard too. Teensy 3.5 and is powerful and low cost, but requires a baseboard and the port isn't done yet. 


Seems good for education and the interpreter is somewhat lightweight like MicroPython but, similarly, choices of microcontroller boards appear to be limited. And Lua is nowhere near as popular as Python so they might struggle more to find help after the club.


This old language lends itself well to education. It's about as lightweight as interpreters come, so I should be able to get a BASIC implementation running on my PIPduino, which would be free for the club (thanks to glacially slow sales).

Coridium's $10 ARM-based BASIC Chip, which is an LPC1114, is designed for embedded use and even the cost of fabbing a baseboard wouldn't kill the budget.

But BASIC isn't standardized across platforms so I'm not sure they could readily apply what they've learned on their PCs like they could with Python or even Lua.

Syndicated 2016-11-08 13:00:00 (Updated 2016-11-08 13:00:27) from Michael Shimniok

Teaching 5th Grade Electronics

I'm pleased to say that I'm shaping young minds into engineers, leading an after-school club called Technology - Robotics - Innovation at my daughter's elementary school.

Week 3 is coming up this Thursday.

Week 1 was introductory and included a fun bridge-building team exercise where we got to flex our teamwork and problem-solving muscles. 

Week 2 the kids had fun learned about electronics: voltage, current, LEDs and built their own LED circuit on breadboards. 

Great news: half the kids build non-working circuits. Exactly what I'd hoped for! See, I didn't tell them that LEDs conduct current in one direction so that they could learn through thinking and discovery. 

Students came up with great ideas on what might be wrong and some discovered that flipping the battery connections lit the LED (nice!). When I told them about LEDs and diodes, they fixed their circuits by flipping the LEDs.

We'll build on the LED circuit and their light-sensing soldering kit circuit to develop sensors for line following. After Thanksgiving, they'll build team robots. Then we'll start on programming!

I plan to publish the curriculum and materials as open source / creative commons for others to use and help us improve it.

This is a dream come true. I've been wanting to teach these things for several years now and I'm super excited to finally have that opportunity!

Syndicated 2016-11-07 19:00:00 (Updated 2016-11-07 19:00:08) from Michael Shimniok

Robot Sumo with Lego Mindstorms

Two deadly, plastic opponents face off.

Their beeps and whirs are drowned out by the deafening cheer echoing in the elementary school auditorium.

Two robots enter the sumo ring. Only one emerges, victorious. The other? Tipped over, out of the ring, parts scattered, wheels spinning in futility...

The culmination of many weeks of tinkering, teams from the Robot Club at my girl's elementary school faced off against teams from two other schools in a Lego Mindstorms Sumo death match (ok, they didn't call it a death match... but I sure will).

For several weeks I came in every week to help the kids design, build, and code their robots and it was incredibly fun and rewarding. Turns out 5th graders are really smart. The kids had no trouble with the LabView-style graphical programming and had working robots quickly.

There were a few physical design issues. Teachable moments in the area of physics were plentiful. Center of gravity. How caster wheels work. Traction, friction. Stuff like that. In the end our school fielded some very competitive robots!

One team started a few weeks behind but was able to build a tracked robot (below) based on some instructions I dug up. They fought against time for weeks and finally, in true robot experimenter fashion, got their code working only days before the competition.

I built one, also. And battled the kids. And lost more matches than I won!

I guess I am not smarter than a 5th grader.

But I definitely couldn't be more proud of these kids for sticking to it, never forgetting to have fun, and building some awesome sumo bots.

Syndicated 2016-05-23 23:30:00 (Updated 2016-05-23 23:30:07) from Michael Shimniok

2 Mar 2016 (updated 2 Mar 2016 at 18:07 UTC) »

Sparkfun AVC 2016

Sparkfun announced that the 2016 Autonomous Vehicle Competition will be happening in September this year!

That's good. It'll be cooler than summer, almost certainly sunny and a pleasant 70-80 degrees. Plus we have loads of extra time to procrastinate. Win-win!

The big news is they're making some kind of addition to the AVC involving -- if the pictorial hint is to be believed -- little kids driving around in home made go-karts?!? Or... I really don't know...

What does it mean!?!?!?
Maybe autonomous road racing? That'd be sweet. Maybe kids will race with bots? Maybe robot kids will... nevermind.

What about me? Though life has been leaving boot prints on my backside for the better part of the last year, IF the AVC additions are super-interesting, Data Bus may have to make a comeback.

I haven't forgotten about rovers. In fact, I've been working on some Rover-related goodies in the meanwhile...

RoverPower [github] is ready for field testing. I wanted to eliminate the quirks of Data Bus' old switched regulator and this new design should do so with extreme prejudice.

It provides rovers with 5V, 1A from an automotive-grade LM2940 5V 1A regulator  [datasheet.pdf] with 6-26V input and low dropout voltage. The current design supports up to 3S battery.

With over-voltage, over-current, over-temperature and reverse polarity protection, not to mention the ability to effortlessly shrug off massive voltage spikes from inductive loads, the LM2940 will survive the worst a Rover can throw at it without breaking a sweat.

And speaking of which, the board's efficient thermal dissipation design mean you get to use all 1A out of the regulator without thermal overload. Filtering capacitors ensure plenty of clean, stable power for sensitive rover electronics.

During initial tests, an earlier version of this design solved spurious resets due to motor voltage spikes on my RedBot (Magician) robot. We saw these symptoms on robots entering the Parker Rover Rally and Data Bus' old regulator would shut down at odd times. This board should solve all of these issues.

RoverPower sits between Battery and ESC with 4 pairs of 5V/GND pins for clean, simple wiring.

This configuration also sets the stage for an I2C-based voltage/current sensor, RoverMeter [github], based on the INA138 (or INA168) sensor IC that monitors voltage drop across a shunt resistor.

Where it's different from the rest of the pack is the addition of an ATtiny onboard that will provide signal processing and an I2C interface so you get stable, accurate measurements.

Good ol' RoverMux is still available on Tindie and in its current revision, is as easy as can be to hook up, while remaining dead reliable. It's been saving Data Bus' bacon since 2011.

My RoverGyro will need a redesign. The chip it was based on was prematurely declared EOL. What to pick instead? A few folks on the DIY Rovers list have been raving about the Bosch BNO055 [datasheet.pdf] which is actually a 9DOF IMU system-on-chip featuring a built-in ARM Cortex M0 performing sophisticated sensor fusion.

I've been tinkering with a few other Rover boards too. Now that the AVC is announced, I guess I better get busy and get these designs finished, tested, and available to buy on Tindie. :)

Hopefully, too, OpenMV Cam rewards will ship in a few months and go on sale, so folks wanting to employ machine vision will be able to do so.

Syndicated 2016-03-02 00:00:00 (Updated 2016-03-02 17:45:55) from Michael Shimniok

Chinese Robot Kit

Kids can build robots, sure, but... which robot kit should be their first?

Lego Mindstorms? Pololu 3pi or Zumo? What would you recommend?

Every time I show my robots to elementary school kids that are really interested in building their own, I realize that I can't recommend a good starter robot kit. Why not?

I feel prospective roboteers deserve a kit that is low cost, can do two or more interesting things, is expandable, and is accompanied both by quality learning material and programming software that younger kids can understand and use.

So, I want to roll my own kit. But, where to start? Maybe... here:

I searched for a low-cost chassis and found vendors on AliExpress selling a robot kit.

It includes an Arduino clone, sensor shield, battery holder, motor driver / regulator board, motors, encoder discs, wheels, caster, and an acrylic chassis.

All for a ridiculously low price. Was it any good? Read on...

Kit Review

What you actually get in the kit is a good start, but you'd need some additional bits to make it all work.

The motors come with wires, mounting brackets and hardware, and encoder discs, but no encoder boards. The chassis and hardware are very similar to the Sparkfun's now-retired
Magician robot chassis.

Pan-Tilt bracket
There's a pan-tilt head similar to the one sold by Adafruit, but the kit includes only one of the required two 90g micro servos. Fortunately I had an extra laying around. The bracket is supposed to clip into some unknown FPV camera, I think.

The power board includes an H-bridge motor driver IC (L298N) with robust heat sink, and a 7805 linear 5V regulator.

However, for all the boards, you must supply the standoffs and mounting hardware and you get to drill your own holes, unlike the Magician. A sonar sensor is included, though with no mounting bracket.

Still, it's a good starting point. Even after you add the missing pieces, total cost should be far south of $100.

You can always add on Sharp IR distance sensors, line following sensors, a robot firefighting apparatus, a claw, or various other things.

Bot Thoughts Electronics?

PIPduino has I2C, SPI,  servo headers.
For my kit, I think I'd rather use in-house, Bot Thoughts electronics. My Uno-compatible PIPduino lends itself nicely to robotics, for example.

My RoverPower regulator board is a good fit, too. I'd need to design a motor driver board, though.

Or, perhaps source a nice switching supply and motor driver from Pololu instead.

The basic kit would have to include encoder sensors and some multi-purpose environment sensing. Expansion kits could be added for specific purposes like maze solving, firefighting, sumo, and line following.


For programming, I know the Lego Mindstorms visual programming language seems to work, because the robot club at my daughter's elementary school use it with success.

EV3 Visual Programming
Scratch for Arduino might be an option; it's for ages 6 and up and is popular, apparently. Or, Minibloq, the first Kickstarter I backed, developed by folks who regularly teach robotics to kids.

For older kids I'm thinking MicroPython would be ideal. Or ... (looks around nervously) ... BASIC, which is what I learned on. The Coridium ARM BASIC chip is an option.

There is something to be said for simple syntax, no semicolons, and no curly-braces...

Well, what do you think? Worth doing? What would your kit look like? Let me know in the comments or click the "Contact Me" link on my blog page.

Syndicated 2016-02-24 00:00:00 (Updated 2016-02-24 00:00:09) from Michael Shimniok

111 older entries...