Octopi and the Select Mini

One nice thing about having a few extra Raspberry PI’s lying around the house is that every now and then a then you stumble on a really cool use case for them.  About a year ago I spent an afternoon installing RetroPi onto one of the Pi’s that I had laying around.  With the addition of USB wireless receiver I was able to hook up some old xbox controllers and before I knew it I was playing some old console classics at home.

My recent endeavors into the world of 3D printing presented another opportunity to put a RasPi to use.  An open source project called OctoPrint allows people to monitor and control their 3D printers across a network.  Since I had an extra RasPi on hand I figured this would be a good use for it.  An added bonus is that it would allow me to tuck the printer into a small space near the window (good for venting when in use) because I would no longer need access to the microSD slot to transfer files.

  • Getting the printer setup in the corner.

Setting up OctoPrint on the raspi was pretty easy.  Just follow the instructions on the website.  Once the Pi is setup, I plugged it into the Select Mini and connected to the octoprint server via a browser.  It took a few tries to get the Pi to connect to the printer, but within a few minutes I was moving the printer head using the OctoPrint controls.  It was pretty awesome.

One word of warning.  In the middle of a print I was moving some of the cords around to make sure they didn’t get caught by the printer movements.  The PI->USB power cord connection isn’t that great, and when moving them around, it may have resulted in a quick interruption in power.  This caused the print to stop.  After digging around, it looked like there was no way to get the print going again, so I had to toss the half finished part and start again.  In normal printing mode (without the OctoPrint) the select mini is capable of pausing and restarting a print based on the user’s commands.  But because the OctoPrint software streams the instructions to printer, neither system is capable of knowing exactly what instructions were executed, so there is no safe way to restart the print. Of course, in normal mode, if you suffer a power interruption, you probably will loose the print as well, so not a huge deal.  But basically as a word of caution, make sure you have a good power connection to your RasPi.  Other than that one incident however, it has been pretty awesome.  I have printed a handful of parts and it is really cool to see the temperature profile of the printer as well as some other stats.

Aliexpress and Beer – Match made in Heaven!

A few Friday’s ago I was enjoying some adult beverages and playing around with some humidity sensors.  I decided it would be cool to expand beyond just measuring humidity and temperature by adding some air quality sensors to the project.  So I dug around on the internet to see what kind of cheap sensors were out there.

After a bit of digging around on the interwebs I ended up on Aliexpress and started adding some sensors to the shopping cart.  I am normally fairly frugal and try to justify most of my expenses, even on hobby projects.  But with the lowered inhibitions thanks to the beer I let myself go a little overboard with the order.  While adding items to the cart, I noticed that the shipping costs added for each part was rather random.  After some further investigation, I stumbled on a neat little trick to keep shipping costs down.  Aliexpress is essentially a portal for sellers and distributors.  From what I could tell, each seller has their own shipping cost rules.  For example, some sellers will add a flat shipping charge for each part, whereas some will discount the shipping costs per part as the order volume increases.  And if you look hard enough, you can find some sellers that charge a flat fee, regardless of the number of parts.  So if you limited your order to only items offered by one or two sellers with the ‘fee per order’ structure (most sellers sell a lot of similar stuff anyways, so it’s not hard to get most of what you need from a single seller), than you can reduce your shipping fees fairly dramatically.  After an hour or two of digging around I queued up an order for a dozen or so sensors and other items for a grand total of ~$40.  Considering how much I can spend at a bar on a typical night out with friends, this was a fairly reasonable total for a Friday night of ‘fun’.

About a month later, the package arrived at my doorstep.  By the time it had arrived (it takes a nice long journey via boat from china) I had forgotten most of what I had ordered, so was eager to check things out.

They packed things in tight.

It’s pretty crazy what you can get from China these days.  For ~$40 I got some CO sensors, Alcohol sensors, soil moisture sensors, some microcontrollers, a camera module, a VOC sensor, and some LiPo charging boards.  This will be enough to keep me busy for awhile and I am excited to put some of these sensors to use!

More 3D Printing “Fun”

lol, Things were going so well… It was too good to be true.

After a rather trouble free introduction into the world of 3D printing, I ended up running into a brick wall of sorts.  I came up with a list of things I wanted to print, and carved out some time on the weekend to get things up and running.  The first item on my print list was a Raspberry Pi case.  I set the printer up and kicked the print off and immediately noticed there was a problem.  The initial lines that the printer was laying down failed to stick to the print bed, and as the printer head moved around they would catch on the head and soon formed a messy pile of printed filament.

In the spirit of keeping this post short (I have a tendency to ramble).  I initially thought the culprit was humidity (specifically, PLA has a tendency to absorb water over time).  I tested this theory by pulling out the small roll of sample filament and attempted to print a bike tool.  Didn’t work.  I then ordered some glue sticks as that solution was mentioned a number of times on internet forums.  Didn’t work.  I sat on it for a week, digging around the various corners of the internet for a possible solution.  Finally, I decided to go back to the basics.  I pulled off the painter’s tape and replaced it with a fresh strip.  I re-leveled the bed, this time being extra careful on each corner (turns out the bed was quite high), and then kicked off a print.  And viola… It worked.

  • First attempt at the pi case, definitely not working.

Still not sure if it was the painter’s tape or the bed leveling that fixed it.  If this issue pops up again I will try and test out both.  Anyways, stoked to have the printer up and running again.  I am going to set it up in a tucked away corner of the apartment so that I don’t have to move it around every time I want to use it (I think that creates issues with the bed leveling).  I am also working on setting the printer up with Octoprint (using a Raspberry PI, which I now have a pretty cool case for) because the printer will be harder to access in it’s new location.   Cheers.

EDIT: Forgot to mention that during all of this I also encountered my first printer head jam.  It was most likely caused by some ‘rouge filament’ that got trapped in the head when I was swapping between the sample filament and my normal roll.  Here is a good youtube video that covers how to deal with these issues: https://www.youtube.com/watch?v=Pgsq297zdAs

Debugging Robot Car


In my last update on the robot car, I had successfully setup wifi control for the car but was struggling with a few issues that need attention.  The first issue was the startup behavior of the car.  On boot, the right motor would spin really fast for a few seconds.  While not a huge deal, it was annoying.  The other issue is that the car seemed to be really underpowered, to the point where it wouldn’t even move when driving on carpet.

My assumption regarding the boot behavior was that one of the pins was getting pulled high (or low?) on boot, which was causing the motor to spin.  The motor spinning by itself wasn’t a huge issue, but it was pulling a lot of current which caused problems when I was plugged into a laptop to load code (the laptop would do an emergency shutoff of power to the USB port).  TO protect against these power surges, I decided it would be a good idea to add a second power switch to the car that I could use to control the motors.  This would allow me to load code onto the esp8266 without having to worry about what the motors would do.

Once I had the switch wired up I switched focus to figuring out how to stop the wierd motor behavior.  I went back to my old trusty debugging methods and pulled a second WeMos out of the part box and an LED.  I loaded the Arduino sketch and proceeded to re-boot the WeMos with the LED connected to each pin.  It turns out the D4 pin was getting pulled high on boot, and that was also one of the pins that I was using for motor control.  I went back to the robot car and swapped out the D4 pin for a different one, and was happy to see the weird motor issue disappear!

Testing the pin behavior with an LED

Once I had the boot behavior issue sorted out, and I turned my attention to the motor speed issue.  One thing that I thought was curious was that the weird boot issue caused the motor to spin really fast, but when I operate the car normally, the motors spin pretty slow.  I played around with the control logic and tested out the speed settings of the motor control board but was only having marginal luck getting the motors to power the car.  It would move really slow on hardwood, and would budge a little bit.

After some internet research, I came to a rough conclusion that the motor board controller was throttling the power to the motors to protect them from damage (which is part of the reason you should use the board) and combined with the low power battery source, the friction from the tank treads (the treads ended up being a  pretty tight fit) and the fact the motors are cheap toy motors, the robo car was struggling to move on rough surfaces.  At some point I will test these assumptions so that I can solve the issue, but after tweaking the code a little bit I was able to get the car to move (albeit very slowly) on the carpet and decided to call it a day.

3D Printed Bike Tools

While digging around on the internet for ideas for my first 3D printer project, I stumbled across some bike modifications that looked cool.  It just so happens that I have a two bikes that are in need of repair.  One bike has a flat tire and the other has an out-of-true back wheel and a few broken spokes.  After reading up a bit more on the mechanics of 3D printing and digging around for some designs, I settled on two files and cleared out one of my Saturdays to attempt the print.

The first print is a spoke wrench.  While these are typically made of metal, I figured I would be able to use this to tighten up and tune some spokes with the tool and then use a normal wrench if I needed more tension.  Plus, this particular object looks like a very beginner friendly print.  I settled on this design.   Before getting started, I spent the morning watching some you tube videos.  This particular series by youtube user ‘Life and Times of Tyler‘ was very helpful. It covered all the basics of getting setup with the Monoprice printer, and he has a lot of very useful advice that I found lacking in a lot of other online tutorials.

After watching some of the videos, I came up with a game plan.  I did a much more through bed leveling attempt this time around (not that that was an issue the with the test print, but just wanted to be safe), and I replaced the scotch tape on the print bed with some painters tape that I had ordered online (the scotch tape that came with the printer was already bubbling after the first print).  I loaded up the spoke wrench STL file into CURA (a program that takes design files and then converts that file into a series of instructions for your printer) and tweaked the setting based on Tyler’s advice.  Because this was a pretty simple part, I didn’t have to mess with the orientation or anything more complicated.  I loaded up the CURA file to the SD card, pre-heated the printer, and kicked off the print.

  • Starting the spoke wrench print.

After about an hour I had a pretty cool looking spoke wrench.  Emboldened by my success, I moved on to setting up the bike tire lever print.  I used this design.  I choose this one because it seemed to have a nice balance between simplicity and functionality.  I wanted to have a spoke hook on the lever because those can be very useful when changing tires, but some of the other designs seemed like they would require support material.  Additionally, the lever looked thick enough throughout that it could feasibly handle the stress of the tire change.  So I loaded the STL file into CURA and started playing around with things.  Curiously, the default orientation when I loaded the file was with the lever flat, with the spoke hook angled up into the air.  It seemed like I would need supports enabled for it to print properly, so I enabled that in CURA.  I was a little worried though because Tyler mentioned that he had a lot of trouble getting the supports to come off cleanly from the part.  I figured there were pretty good odds that these tire levers weren’t going to hold up the stresses of real life, so I pushed forward with the print as-is because I figured it would be good to see what how these support structures work.

Sure enough, after the print was done. I attempted to remove the support structures (see photos in slide show) but it was pretty difficult.  I ended up using a razor and file to pull the material off, and in the end still ended up with a very rough surface.  I decided that for the second tire lever, I would print the lever on it’s side which seemed like I could get away with out support material.  Another possible advantage of that orientation was that it could increase strength of the part (3D printers are stronger in the x-y axis, and weaker in the z axis).  So I went back into CURA and made the changes and then kicked off the print.

The second tire lever turned out surprisingly well.  I went online and ordered a new bike tube for one of my bikes.  Once the tube arrived, I got to changing the tire, and I successfully removed the tire without either of the levers breaking.  I did chip one of the levers (the one printed flat) when attempting to put the tire back on (partly my fault, I was hammering it against the tire bead to try and get the bead back in the rim, the lever definitely wasn’t built for that abuse).  So all in all, I consider this little project a success. I could have bought a cheap pair of tire levers online, but it was good to get some more experience with the printer.  Also, I am still waiting for some replacement bike spokes to get shipped, so I will update the blog once I get around to using the spoke wrench.  Cheers!



Setting up Wireless Control of Robo-Tank!

After getting the electronics working, my next goal was to set up some rudimentary wireless controls for “remote” operation.  I was hoping this would be pretty straight forward because I was using my esp8266 as a microcontroller which has a built in wifi chip but I ran into a few issues along the way.  But after some elbow grease I eventually got the robot to take commands from a remote server.

The first step was to mount the electronics onto the chassis.  This was probably the hardest part of the build so far.  I wasn’t using an off-the-shelf kit, so I had to design the rig on my own (I was able to get some inspiration from the internet).  And because i don’t have a workshop, it is difficult for me to fabricate custom parts/mounting hardware[1].  So I was stuck digging around in my parts box to try and hack something together.  The simple solution would have been to just mount a breadboard directly onto the chassis, but there wasn’t enough room due to the gear box.  After playing around with some different configurations and digging around on the internet, I ordered some standoffs and some prototyping boards from amazon.  I figured I would mount a prototype board on to the chassis using the standoffs to create a ‘double decker’ of sorts.

Of course, the mounting holes on the prototype boards were too small for the standoffs that I had ordered.  It turns out the one of the pieces of the proto-snap mini bot (that I had scavenged some parts from) had mounting holes that worked with the standoffs.  On top of that, it had a ‘blank’ section of PCB that I could attach a small breadboard to, so I settled on that configuration.  I ended up being pretty happy with this configuration, because I was able to rest the esp8266 and the motor controller on the thru-hole section of the PCB, and then use the breadboard to wire everything up.  It is a pretty tight fit, but it is stable enough and because I didn’t have to solder anything, I can easily test different configurations until I settle on a more permanent setup.

Once I had the PCB mounted, I used double sided tape to attach the battery holder on top of the gearbox and I wired up a on/off switch onto the breadboard.  I ran a few tests to make sure that things were wired up correctly and then switched focus to the Arduino code.

  • I set the robot up with a elevated breadboard to allow for quick prototyping.

One of the cool features of the esp8266 is the possibility of doing Over the Air (OTA) updates to the microcontroller.  Normally when you make changes to the code you have to plug your connect your microcontroller to your computer via USB to make the update.  This can be annoying if your microcontoller is mounted in a hard to access area.  So I was excited to try out OTA on this project.  When using the Arduino IDE, you simply add some OTA code to your script which allows future updates to be delivered OTA.

Unfortunately, OTA wasn’t really working for me.  I had tested OTA updated on a bare WeMos and got it working, but I couldn’t get it to work with the robot car.  I didn’t spend a lot of time looking into the issue.  My guess is that either the battery power was too weak to allow for a re-boot/update while connected to all the other electronics on the car (wifi is a big power hog), or the OTA code was conflicting with some of the other code I had in my Arduino script.  I tabled this issue for now and will follow up when I have some more time.

In order to control the robot car, I wrote some code to send http commands to the esp8266 from my computer.  The esp8266 was setup as an http server.  It parses the parameters of any  incoming GET request which then sends the appropriate signals to the motors (forward, left, right, back, and speed).  On my computer, I wrote a little python script that sends http requests based on keyboard input.  After a few tweaks and bug fixes, I got everything to work and was successfully controlling the robot car from my computer.

While the car was technically working, I still have a lot of work ahead of me.  The robot is very slow and underpowered, to the point where it can barely move on carpet.  I tired playing around with the speed control on the motor controller, but didn’t have any luck improving it. So this is something I need to look into.  Also, the robot has a weird startup behavior.  On boot, the left motor spins really fast for a few seconds (and the funny thing is, its a very fast spin, if only I could get it to do that during normal operation than I could drive it on carpet!  Ugggh, hardware!).  My guess is that it has something to do with a few pins getting set high (or low) on boot.  So I will need to look into that as well.

Anyways, the progress has been good so I am happy.  Once I get some of the issues hammered out and clean up the code I will post that to Github, as well as add some follow up posts.

[1] You may have seen my previous post on getting a 3D printer.  The hack session that I am writing about in this post pre-dates that event by a month or two (I often start writing the drafts of these posts soon after the event/topic that I am writing about, but don’t get around to finishing/publishing them for a few weeks or more, so the timelines are bit out of whack here.).  So yes, I now have a 3D printer, and that would have helped quite a bit in building out this bot.  But I am also 3D noob, so it will probably be a few months before I can take full advantage of it.

I got a 3D Printer!!!

I hope everyone had a Merry Christmas! I was rather surprised to find a 3D printer under the tree this year.  My girlfriend went in with some of my family and got me a MP Select Mini 3D Printer.  While the gift wasn’t totally unexpected as I had dropped a few hints, even at ~$220 it was well out of the range of what my family normally spends on gifts (hence the group effort).  And while I thought it would be cool to own one, I admittedly don’t have a ton of immediate uses for it and found it difficult to justify the impulse purchase considering I live in a pretty small apartment and space is at a premium.  But in the spirit of the excessive and unnecessary consumption that typically accompanies this wonderful holiday, I suppose I can allow myself to indulge a little bit in this unexpected surprise. All things considered, I imagine I will get more use out of the 3D printer than the more typical oversized sweaters and sheet sets that tend to get tossed into the closet only to be donated to goodwill a few years later.

I don’t have a lot of (any) experience with 3D printers, so I am not even going to attempt to review or provide any sort of significant feedback on this thing.  If that is what you are looking for, then I would recommend this rather excellent review of the printer on Hackaday.  In short, the MP Select appears to be a great starter printer that provides comparable performance to printers that are even 3x more expensive.  So if you are looking to dip your toes into the 3D printer market, it sounds like this is probably the best printer to start with.

I was able to get the printer up and running fairly quickly.  The printer comes mostly pre-calibrated (not really sure what that means), the only calibration required of the user is to level the bed.  I followed the bed leveling instructions (involves adjusting the four screws holding the print bed in place, and using a sheet of paper to set the gap between the print-head and the bed).  A quarter-turn of each of the screws was all that was required[1].

My gf and family were prescient enough to also get me a few spools of PLA filament (the printer comes with a very small amount of test filament, but not enough to do anything significant).  So I set up the appropriate temperatures (still not sure what bed temperature to use, but 50 C seemed to work).  The printer comes with an SD card that already has some test print files on it, so I loaded that up and kicked off a test print.  However, I immediately noticed an issue.  As the printer head was moving into position, filament was ‘leaking’ from the head.  So traces of printed material were getting dragged around the print area and creating a nice little mess of things.  After a quick internet search, I decided to lower the print-head temperature by 10 degrees, and that seemed to do the trick, and I kicked off the test print.

  • Test print getting started!

The test print took about 3 hours, and seemed to go perfectly fine.  At one point during the print, I got a little panicked as the printer seemed to be printing material in the ‘wrong’ area, and it was creating a little bit of a mess.  But it turns out, the printer was attempting to print the paw of the cat, which hangs over the belly, and after a few passes in that area, the base of the paw eventually formed and the print carried on unaffected.  If you read the hackaday review, it sounds like this model of printer has some issues with printing overhangs and bridges (areas of a print where there is no material underneath).  This is partly due to the lack of a second cooling fan on the printing head (but is an issue with current 3D printers in general).  If you look closely at the photo in the slideshow, you can see some errant material under the paw.

Another concern I had was with the air quality in the room.  There have been a few studies and articles on the topic, and it was one of the reasons I was hesitant to splurge on a printer in the first place.  As I live in a small apartment, I don’t have a lot of options for places to put the printer.  For this test print, I figured I would go ahead and print in my living room so I could keep an eye on it.  And sure enough, about half-way into the print, there was a very distinct ‘plasticy’ smell that filled the room (and this was with windows open and an air purifier running nearby).  Assuming I am not printing 24/7, the emissions are most likely tolerable (probably not too dissimilar to the VOC risks from your soldering iron), but this is a very new technology so we don’t really have any way to know for certain what the long term impacts are, so it is probably best to air on the side of caution.  So for future prints, I am thinking I will either put the printer in our garage (which is a little tricky cuse it’s a shared garage for our partment) or build an enclosure with a filtration system.

With that disclaimer out of the way, I can confidently say that this little 3D printer is pretty awesome, and I am excited to put it to use on some of my projects.  I don’t have any concrete plans at the moment, but I will most likely start by making a few project enclosures and other simple items/trinkets. But it would be cool to eventually print some parts for a robot or some other mechanical pieces for projects (one of the downsides to living in a small apartment is I don’t have a workshop that allows for fabrication, so in theory, a printer could help fill that gap a little bit). Anyways, I am looking forward to what the new year has in store, and I will keep you posted on any developments. Cheers and Happy 2017!

[1] I am a little concerned about the simplicity of their leveling instructions.  You set the printer head to ‘home’ (which puts the head on one corner of the bed) and then they have you use a piece of printer paper as a proxy for 0.05 mm spacing measurement.  So you adjust the bed until you can slide the piece of paper between the printer-head and the bed.  But it seems to me that if you don’t evenly adjust all four corners of the bed, or if the bed was already a little ‘un-level’, than you wouldn’t have a level bed. (i.e. I feel that you either need to have the print head move to all four corners, and then do the ‘paper adjustment’ on each corner, or you need to use a leveler tool to adjust the bed (although that would level the bed based on gravity, and not necessarily to the orientation of the printer (i.e. if the table the printer sits on is a little unlevel, that would cause issues).  Anyway, going off on a tangent here.  This is something I should probably follow up on a little, but my test print came out fine, so probably not a big deal.

Breadboarding the Robot Tank Electronics

With the tank chassis set up, I started working on breadboarding the electronics for the robot.  My plan was to salvage the motor driver from a dead MiniBot board, and use a WeMos D1 Mini as the microcontroller.  Here is the part list for this build:

  • Tamiya Tank Chassis w/ Gear Box and motors (see this post for details)
  • WeMos D1 Mini
  • TB6612FNG Motor Driver Board (taken from a MiniBot protosnap board)
  • Misc: a lot of jumper wire, a breadboard, and a breadboard power supply

Unlike most of my build days, this one went pretty smoothly.  The one issue that I encountered was that the MiniBot version of the TB6612FNG was a little different than the version that is more commonly sold.  Fortunately, the MiniBot kit had sample code that I was able to pick through in order to properly control the motors.

  • Snapping off the motor driver from the MiniBot board

Another issue I had was with the OTA updates (Over the Air).  The esp8266 addon package for Arduino included sample code for enabling OTA updates.  I did a few tests with the OTA code and was able to use it somewhat successfully, but I was getting some weird behaviors when I incorporated it into the tank sketch.  I think the issue might have to do with how WeMos resets itself.  It looks like one or two of the pins that I am using to control the motors get pulled high on reset.  This causes the motors to start spinning, which could cause some power draw issues.  I will need to investigate this a bit more later, but for now, I am happy with the progress and looking forward to setting the tank up so that it can be operated over WiFi.

Assembling a Robot Tank Chassis

A few nights ago I got around to putting together a tank chassis for what will eventually become some sort of robot tank.  I am still not 100% sure what the goals are for the robot.  I know I want to be able to control it over wifi, and I will most likely have some form of distance measuring sensors for obstacle detection.

A few years ago I had ordered a MiniBot kit from sparkfun.  I wrote a few posts on some of my experiences with the kit, but the tldr was that the FTDI chip on the board was faulty, and while Sparkfun was nice enough to send out a replacement, it was a long while (due to my own procrastination and some other obstacles) before I actually had a working bot.  During that period, I had been ordering some parts here and there for planned upgrades to the bot (it was designed to be very customizable, which was cool).  After a while, I realized that I had enough parts to build a second bot from scratch (in part thanks to the faulty board that originally came with the kit, some of the components were salvageable).  So I figured, instead of chopping up the working MiniBot, why not just build a second one and have two!

The first step in building a tank robot is to setup the chassis.  An RC company called Tamiya sells some parts that make this pretty straight forward.  Here is a list of parts that I used, you can find these on Sparkfun, Amazon, and a number of other websites:

  • Tamiya 70168 Double GearBox
  • Tamiya 70098 Universal Plate
  • Tamiya 70100 Track and Wheel set

The first is a gear box which allow us to transfer power from the electric motors to the wheels.  If you are unfamiliar with electric motors and you have a few hours to kill, I would recommend doing some reading on the topic as it is pretty fascinating.  But in short, for most motors, especially the ones you are likely to find on hobby robots, you need some type of power transfer system.  Hooking the motors up directly to the wheels will result in burning your motors out.

The gearbox assembly was a bit complicated, but not necessarily difficult.  The tricky part is that you need to have all of the drive shafts and gears lined up properly before you can tighten down the housing to hold things in place.  So it might take a few attempts, but once you get a sense of how the gears are supposed to fit together, it is pretty straight forward.

The universal plate is a nice mounting option for your gearbox as well as the the track and wheel set.  Tamiya clearly designed these three parts so that they would work together.  For some reason the latest version of the twin gear box was widened such that the mounting holes are now wider than the plate set.  The downside is you now have to make some cuts to the plate set and use a mounting adapter (included with the gearbox) in order to mount the gearbox. I’m sure there is a reason for it, but seems like an odd design choice considering these three components were clearly meant to work together.

  • The gear box parts!

Once the gearbox was mounted to the plate set, I mounted the track and wheel set.  I dug around online to see what some of the possible configurations were, and I think I settled on the best configuration that requires the least amount of custom modifications (see the slideshow for the configuration).  Depending on the electronics that you plan to use and your ability to build/modify parts, you may want to change the design up.  For example, this robot configuration seems to be a fairly space efficient configuration that doesn’t require too many modifications to the parts.

Now that I have the robot chassis assembled, my next task is to start getting some control electronics working.  The plan for now is to prototype on a breadboard, and then if possible, either mount the breadboard, or move the components over to a prototype board.  Either way I am looking forward to getting the robot up and running.  My cat needs someone(thing) to keep her company during the day!

The Joys of Hardware – Part 2

In my previous post, I discussed some of the ‘fun’ that I have had working on hardware projects, and in this post I will be pushing that meme forward a bit.

One of the few successful projects that I have managed to pull off was a temperature sensor to monitor my homebrew fermentations.  I had a few of these units set up, and they would monitor the fermentation temperature as well as the ambient temperature and send the data to a server.  While the project sounds pretty simple, I had hacked together a fairly complex solution (temp sensor hooked up to an arduino hooked up to a Raspberry Pi) because sending data over wifi from an arduino usually requires buying a rather expensive shield (basically an add-on board for the arduino).  One of my goals after finishing the project was to revisit better ways to send the data.

A few months after I had finished the temp sensor project, a little board called the esp8266 started to get some buzz on the interwebs.  The board was made by a company in China called Espressif and it was getting a lot of attention because it was a fairly cheap microcontroller that had built in wifi.  At the time, they were hard to get a hold of and they were poorly documented, so I decided to explore some different wireless options and wait to see how things would play out regarding the esp8266.

After about 6 months, a community started to build around the esp8266 and development boards were being offered by a number of different companies.  I hadn’t made much progress on the temp sensor project thanks to the usual distractions, so I figured I would order up a few development boards (WeMos).  After I received the boards, I read through some tutorials to figure out the best (re: easiest) development setup (a few different solutions were available to program the board, some more complicated than others).  I decided to try out using the Arduino IDE with the esp8266 addon as I was already familiar with that environment.

Once I had the esp8266 addon installed, getting the WeMos to run the blink sketch using the onboard LED was pretty straightforward, which was encouraging.  Next, I started playing around with some of the boards Wifi capabilities.  I found a sketch online that connected the board to an access point, and also scanned and printed out a list of accessible wireless networks.  After a few fits and starts (not 100% sure what the issue was, but seems like you need to reset the board before you can upload a new sketch, and possibly unplug and replug the usb/power cable), I got the code uploaded and was happy to see the WeMos reporting back the local wireless networks to my serial monitor.  Now that I had some momentum, I figured I would take a stab at setting up the temperature sensor and see if I could get the WeMos to report the data to one of my servers.

I spent an hour or two cobbling snippets of code together that I had found on the web.  From what I could tell, the Arduino sketch to read data from the temp sensor didn’t need too many modifications to get it to work with the WeMos (which is awesome) so I figured I could use the code that I wrote when I first attempted this project (using arduinos).  After assembling a sketch together I loaded it up and held my breath…

And of course it didn’t work.  This kicked off a round of fruitless troubleshooting.  I stripped the code apart and tested out the pieces individually to see if I could pinpoint the issues.  Turns out I needed to make some modifications to how the data was getting sent to my server, and after some tweaking was able to send some dummy data across the network.  Once I had that bit up and running, I tried loading the temperature sensor portion of the sketch, and while it successfully loaded, I was getting bad data in the serial monitor.  At this point it was getting late, so I decided to head to bed and re-visit the issue at another time.

A few weeks later (I really need to get on a more regular hacking schedule) I carved out some time to work on the project.  While I still wasn’t sure what the issue was, I had a few hunches that I was going to try and test.  In order to help diagnose the issue I also set up an Arduino microcontroller with another temp sensor, so that I could go back and forth between the two to try and better diagnose the issue.

  • Always try the blink sketch. If you can't blink, you have problems.

I tried a few different things to see if I could isolate the issue.  I set up an external power supply on the hunch that the wifi chip in the WeMos was drawing too much current from USB, but that didn’t yield anything (and I think my breadboard power supply was actually not working that well, you get what you pay for!).  I tried out a few different tests like swapping pins (WeMos has different pin layout which doesn’t correspond to the arduino pin layout) as well as testing voltages and currents.  But nothing was yielding any promising results.

In a fit of frustration, I grabbed an led and some jumper wire, and decided to go back to the basics and test out the Blink sketch[1].  If I couldn’t get an LED to blink than I either had a junk module on my hands or I just wasn’t cutout to be a hardware guy.  I set everything up, uploaded the code and … unexpectedly, instead of a nice steady blink, I got a few sputtering flashes. hmm….

To cut to the chase, it turns out you can’t just push some headers through the pinholes of the WeMos to connect it to the breadboard and expect solid contact[2].  In my defense, I had done this before with some other boards and it worked fine, so it’s not like I was being super naive about it (well I kinda was).  After this realization, I pulled the WeMos off the breadboard, and then wedged the LED into the pinholes and …. SWEET!!! It was blinking.

Know that I had a reasonable idea of what the issue was, I set about to soldering some headers to one of the boards.  It was a tight fit, and I may or may not have a few pins that are now connected to each other via some sloppy solder, but I did my best to isolate the pin that I was going to use for the temp sensor, and then popped the board back into the breadboard.

And wouldn’t you know, worked like a charm….

[1] The Blink sketch is the ‘Hello World’ of microcontrollers.  You hook up an LED, and then tell you microcontroller to blink it.  When I initially played around with the board, I had run the blink sketch using the onboard LED, but had not attempted to wire up an external LED.  In hindsight, that should be the first thing you do with any new microcontroller.

[2] The WeMos D1 mini comes without headers soldered onto the board.  But they provide some headers that you can solder on if you need them.  In order to ‘preserve’ the board (headers can be a bit bulky, making the board harder to use in smaller projects) I was just pushing the headers through the pins and then pushing them into the breadboard, and using some pressure to ‘ensure’ contact between the pins and the breadboard.  Turns out I wasn’t really getting any contact.