May 10, 2014

A Maker in the Quebec Fortress

A couple of weeks ago I saw a tweet from @hackaday about their new hacker contest.  The prize is only a trip to space... an actual trip to space worth around 200k.  That evening I was browsing the contest page to get more details and then I reached the eligibility section where it stipulates that the following can't participate: [...]Quebec, Italy, Cuba, Iran, Myanmar (formerly Burma), North Korea, Sudan, Syria, or any jurisdiction where the Contest would be restricted or prohibited by law [...]

The thing is, I was not too surprised since this happens often in Quebec where we have some retarded laws to control the lotteries.  Quebec is surely not the only place in the world where lottery & gambling is controlled but I think we're the only ones that are dumb enough to think that we can control all the world-wide lotteries. The result is that Loto Quebec, the government body controlling this, is trying to impose those crazy conditions on out-of-Quebec contests. So any contest with a prize must submit to those conditions and guess what, for only a small pool of 6 million people, they don't.  You ear that, contest organizers from around the world? Keep your free money and space trips. We have maple syrup.


So I can't register my project on Hackaday. Life goes on.

I recently acquired an Ultimaker 3D Printer and that was a huge moment for me.  I have so many projects that can benefit from this that I don't know where to start.  After a few days of learning the limits of the printer I was ready to start working on a project, and to make it even better why not a contest. So I returned to an old ongoing Intel contest page: the Make it Wearable Video Contest.  This place is a really cool mix of art, technology and people that I want to connect with.  Well you know the twist of that story.  This project [...] is open only to legal residents of Argentina, Canada (excluding the Province of Quebec), [...].


So I was ranting to people at work about the stupidity of this law but, deep inside, I thought that it wasn't too bad for now and that I could still connect with the Maker community through blogs, videos, twitter and so on.  “I'm a good sheep, I am.” (in the voice of My Fair Lady)

Then, a couple of days ago, the proverbial sh*t hit the fan.

My 9yo son who plays with LEGO Mindstorms found out about the MoonBots contest, a Google Lunar XPrize LEGO Mindstorms Challenge.  This an awesome international on-line competition for kids (9 to 17) where you have to simulate a moon mission.  Needless to say that we were bouncing ideas around and, as the vision of the project took shape, a shiver ran up my back.  I went to my computer and checked the small prints...  guess who can't compete? [...] Cuba, Iran, North Korea, Myanmar/Burma, Zimbabwe, Sudan, Syria, Argentina, Quebec, any other U.S. sanctioned country [...]

$^%&#@#$#&^ You're messing with my kids now.  The gloves are off and Nova Scotia looks like a great place to live.  Maybe I'll shop around for houses.

Where is the best place on earth for a family of Geeks and Maker?

Mar 18, 2014

Stealth Evolution

I thought I was following the evolution of the stealth technologies but I had to tweak my understanding based on recent events.

LEGO Test machine #2 is dead after 1 test

Well, that didn't last long.

The machine did 1 full test and then died at about 1/3 of the second test.  The first test result is 32,066 iterations, supporting the result from the Test Machine #1 which ended with 37,112 iterations. So the average is at 34,589 for the moment.

So, why is the machine #2 dead? It didn't died as much as it was slaying DC motors and it all came down to a bad design. One of my goal was to build the machine with only (as much as possible) the Makeblock parts that TLBRC* sent me.  It turns out that I found my nemesis in the motors that where included in the two kits. DC motors.

For something like this build, every molecules in my body was screaming stepper-motors or, at least, servos.  But NoooooOOOoooo, it had to be DC motors, so I looked around for ideas to use them in the same way I would use stepper-motors.   The result was to build physical barriers to stop the motor in known positions.  I knew this would not be good on the motor's gears so I monitored the current going into the DC motors and “tried” to stop them before they were straining. At this point in the story, all the engineers are rolling on the floor laughing. Well, 3 dead motors later, I've learned my lesson: Engineers are cruel and, most importantly, DC motors and made to run freely like wild mustangs in prairies.

The following video was made after the machine killed its first motor.  At that point I thought I could fix it:

Here is my sad video when I decided to stop the machine for good:

What now?  Thanks to Galaxy Quest, my motto is “Never give up, never surrender” and so I have 2 plans:

  1. Build a simple machine using stepper-motors.
  2. Find a DC motor friendly design and try that too.

But, in order to keep my sanity, I will take a short break from this and work on other projects.

R.I.P. LEGO Test Machine #2.  At least you did 1 full test.

*Again a big thanks to The Little British Robot Company for the 2 Makeblock kits that were used for building this project.  I will reuse those parts on a project pretty soon

Jan 7, 2014

HC-05 Bluetooth link of 2 Arduino

In my first Arduino bluetooth experiment, I made an automatic connection between 2 Arduino using BlueSmirf modules. Based on the popularity of that post, it seems that many people are trying to do the same.

On the down side, many of the visitors are looking for a solution using the HC-05 (or other HC-XX type) modules with an AT command interface. I planned to eventually use this type of device but never got around to doing it for every bad reason imaginable including procrastination. This delay was clearly unacceptable for Lyman (one of my readers) who decided to send me 2 extra modules he could spare.

On a side note, this kind soul only has 2 followers on Twitter. Please help me fix this grievous situation.

After playing a bit with my new toy, here's what I've got:

In this first simple example, the code sets the module to be either Master or Slave, connects to one hard-coded address and starts the communication loop. While connected, the Master sends 1s and 0s to the slave who is using this 'command' to switch an LED on or off.

You can get the code on this Git repo.

Breadboard diagram (without the reset connection)

The biggest problem was to figure out how to reset the module programmatically. The [not so good] documentation explains how this can be done by cycling the power but the bluetooth chip has a reset pin that is supposed to do the same trick. I have the code to use the reset pin which I got from this blog post and I will test it soon.

On the HC-05 modules I received, the reset pin is not connected which 'forced' me into making a little hack that can barely be noticed...

The next step will be to recreate the same query and auto-connect loop that I did with the BlueSmirf. It should be straight forward since I've already tested all the necessary AT commands successfully.

Dec 31, 2013

Profiling DC motors

For the second design of the LEGO test machine #2, I stopped using rotary encoders an switched to ACS712 lowcurrent sensors.

I initially hooked them to a multimeter and an Arduino to tweak the 2 potentiometers of the sensors. Following some of the steps from this MobileAPES post, I've set the voltage (Vref potentiometer) to 2.5v without any problems but the gain (GAIN potentiometer) was initially tricky. Back when I was using the rotary encoders, I was running the motors as slow as possible (speed of 65-85) in order to not stress the parts. At those speed the current fluctuations are too large and I had to find out what is the optimal low speed of the motors.
I decided to log the data out to better see what was going on. The initial test was to log the current sensor values every 1ms while raising the motor speed from 64 to 210 by increment of 5 every 20ms. 

Yellow=speed / Blue=running freely / Red=stalled (prevented from turning)

Clearly the values I get from the motor is erratic when the speed is below ~110. So I profiled the motor again from 130 to 230.

Yellow=speed / Blue=running freely / Red=stalled (prevented from turning)

Now I know the how slow the motors can go and how to detect a stall using the current sensor. This also told me how long the motor takes to ramp up to speed when initially set at a speed of 130.

Here's the diagram of the machine made with Fritzing:

I don't have the Adafruit motor shield [fritzing] part so I used the Arduino motor shield rev3 instead. The missing details are the following: The servo is connected on SER0 (pin 9), the push-down motor is connected on M2 and the lift-arm motor is connected to M3.

The code and the Fritzing diagram for this new version are available on git.