His First Robot

We just finished this project so a created a page just for it.

This is a 5 hours project with my son Gérémy (7 years old at the time) who showed interest in doing some robotic using our old LEGO Mindstorm by building an RC car and wanted to build the RCX line following robot described in the Mindstorm books[...]

... read about the whole project

A new life for RCX 2.0

My LEGO Mindstorm had been unused for years now especially since I started using micro-controllers like BasicStamp and now Arduino. It had a short revival last winter when I used it to build a Star Wars R2-Unit crane for my twins. It was a real success and they played with it for two weeks straight.

Initially I was happy that my RCX was being used again but very puzzled that, after that playing stint, they had not included this new motorized brick into their regular LEGO play. Why? Maybe the cabling or specially the gears were a bit much for their age (7).

Lately my son made yet another awesome LEGO thingy and I told him he could make one part spin if he used the motors. He suddenly looked defeated and told me that “the pump thing is hard”. I finally knew why he was not using the RCX. He thought that the pneumatic system we used when making the crane, was the only way to make a working machine. Happy to enlighten him, I explained that he could use the motors alone and, at that very moment, I saw that his little brain was about to explode with ideas while he ran back to the LEGO boxes. His first creation was this 4 wheeled vehicle with one motor per wheel.

Then he dug up my old LEGO RCX 2.0 Mindstorm book that came with the kit, went through it one evening, found a line-following robot and built it the next day. I heard the perplexity in his voice when he called me saying “It's not working!”. The robot, going in circle, was missing the right code. I told him that building the physical robot was half the job and that it needed a program to tell him what to do. Of course now he wanted us to put the program in the robot.

I didn't want to disappoint him but the last time I pushed code on an RCX brick was in 2001 with a Windows XP computer. The software CD was probably lost in some storage box and, adding to the problem, loading a program must be done using a LEGO Infrared USB device (LEGO USB Tower) which are probably not supported anymore. Or so I thought.

I recovered my LEGO USB Tower and, ready for some major Internet archeology, Googled about LEGO RCX. I quickly found that Not Quite C (NQC) was still going strong. It was the programming language I used 10 years before. Not only that but I found that the LEGO USB Tower was now directly supported into Linux. So I plugged it in and BAM! /dev/usb/legousbtower0. Minutes later I uploaded a test program on the RCX brick and ran it. Victory is ours!

I coded a very simple program to show my son some basic logic in programing and now he's completely shocked by the fact that he can make a full robot, including the code.

I've created a monster and I like it.

More Geek info after the break

Arduino and Micro-SD logging

Getting started with Adafruit's Micro-SD Breakout Board in 2 minutes.

Wiring

Wiring the Breakout board is very simple.

• Connect the 5v pin to the 5V pin on the Arduino
• Connect the GND pin to one of the three GND pin on the Arduino
• Connect CLK to pin 13
• Connect DO to pin 12
• Connect DI to pin 11
• Connect CS to pin 10

Picture shamelessly taken from its home at adafruit.com

Programming

To use the Micro-SD you need to include the SD.h library at the top of your program.  Then add the following line of code to your setup() function:

SD.begin(10);

Now you can write something on the card:

File logFile = SD.open("log.txt",FILE_WRITE);

if(logFile){

   logFile.println(“Hello World!”);

   logFile.close();

}

Finally, while humming the MissionImpossible theme, you can power off the Arduino board, take the Micro-SD card out, put the micro-SD card in an SD card adaptor, put the SD card adaptor in your laptop and look at your new file.

Muha ha ha ha ha.

Note: I used this in my last arduino/bluetooth project.   

Arduino Bluetooth Link

In a previous Arduino project, I used the BlueSmirf Bluetooth Breakout Board to communicate with my Android phone. There was absolutely no special code on the Arduino to handle Bluetooth since, by default, the BlueSmirf is set as Slave and will accept any connection call. The phone app was doing all the work.

The next logical step was to use the BlueSmirf interface by programming the Arduino. Using a second Bluetooth board, I decided to create a link between two autonomous Arduinos. To make things interesting, I've set a couple of rules for the project. I wanted to heave the same code on both Arduinos and have the whole connection process be automatic. I also wanted the Master device to scan for other devices, retrieve the MAC address, connect and send data.  Here's the video of the final result:



My biggest issue started with the Sparkfun proto shield for Arduino. It has a built-in socket for their Bluesmirf device. Nice marketing move! This socket is hardwired to use the Arduino pins 0 and 1 for communications. It all looks good until you need to use it in the real world. Here are the pros and cons:

Pros:

• No wiring needed to connect the Bluesmirf board.
• No extra library needed to do serial communications.

Cons:

• You must remove the Bluesmirf breakout board every time you need to plug the Arduino board in the computer. Why? Because of the hardwired Bluesmirf socket the Arduino board communications are mixed with the Bluesmirf interface.
• Another consequence of the previous problem: You can't used the USB serial output to the computer to send debug info. That is really annoying when debugging your project.
• The power is always ON for the Bluesmirf.

I'll fix this by using different pins for the Bluetooth communication using the NewSoftSerial library. I will also modify the Sparkfun Bluesmirf socket to use any communication pins and to have control on the power usage.

For more details continue reading after the break. (Warning! Geeky stuff about code and electronics)

The deep end of the pool

When we think about Cloud computing two big players come into mind; Microsoft Azure and Amazon Web Services (AWS). A lot of people think that ‘Cloud is Cloud’ so both of them must be offering the same product, right? Well, one major difference between the two may change this point of view. Their philosophy of cloud development is radically different.


Before talking about those philosophies, another obvious difference must be mention. AWS is an Infrastructure as a Service (IaaS) while Azure is a Platform as a Service (PaaS).

Because a Cloud infrastructure is analog to a Grid infrastructure, processing can be distributed between multiple instances. So, for a process to really use the Cloud power it should be highly parallelized. Also, anybody that look into Cloud development long enough realizes that scalability and reliability can only be achieve through an abstraction layer (PaaS) that will manage self contained tasks and will be resistant to the failure of one or many instances. Finally, we also know that the state of availability in a Cloud will change over time. A Cloud process must adapt to that change and should proactively monitor availability instead of stopping when encountering availability issues.

This level of development architecture is not easily achieved. Developers who find that simple are most probably using other important principles like multi-threading and error recovery. This can all be done on a multi-core computer. When you add the complexity of distributed computing (grid computing), development architecture becomes even harder.

Now, back to philosophy.

When approaching Cloud Computing, the architect of a non-optimize system must decide to either, continue using their current philosophy or upgrade it by including parallelism, resilience to task failures and adaptation to changes in availability. This can be an overwhelming task and some architects choose the status quo.

The difference between Microsoft and Amazon is that Microsoft’s Azure is adhering to those optimization principles and therefore steer the users toward developing that way. On the other hand Amazon provide access to a bare bone IaaS the lets you run your processes no matter how non-optimize they are.

So, there you go. For non-optimized developers, developing with Azure is like learning to swim by jumping in the deep end without a flotation device.


I like the challenge!

Android is smoking

This is my first Android development test using the NDK and OpenGL-ES. I quickly adapted some simulation code I found on the web and rewrote the rendering layer to make it compatible with OpenGl-ES. I also fixed a couple of bottlenecks to make it run faster. Here's a video of the result.



So far I like working with the Android NDK and OpenGL-ES although I'm not a big fan of the Eclipse IDE (development environment). Now I'm going to start a shippable project to really get the feel for this new platform.

The neverending Story Points

Here's my second shot at explaining Story Points for estimation in Scrum:


When I switched to points I decided to if I could meet those two points;
1) find and argument that justify the switch and that will convince the team
2) Find an easy method to use it.


Phase 1: Convincing
It took me a lot of reading on the subject but a finally found the argument that convinced me and my team: It’s nearly impossible to find two programmers that will agree on the time a task will take but the same two programmers will almost always agree on which task is the biggest when shown two different tasks.
This is the only skill you need to ‘estimate’ your backlog. Here I use the word ‘estimate’ but at this early stage it’s more like ordering the backlog from tough to easy.

Phase 2: Putting Points in the Backlog
This step is done with the participation of the entire scrum team.
Start dropping the stories one by one in a new spreadsheet while keeping the following order: the biggest story at the top and the smallest at the bottom. Do that until all the stories are in the list.
Now it’s time to put points on those stories. Personally I use the Poker Planning Scale (1/2,1,2,3,5,8,13,20,40,100) so this is what I will use for this example. At the bottom of that list you’ll probably have micro tasks (things that takes 4 hours or less to do). Give to every micro tasks the value of 1/2. Then continue up the list by giving the value 1 (next in the scale) to the stories until it is clear that a story is much bigger (2 instead of 1, so twice bigger). Now using the value '2', continue up the list until you find a story that should clearly have a 3 instead of a 2. Continue this process all the way to the top of the list.
NOTE: Try to keep the vast majority of the points between 1 and 13. The first time you might have a bunch of big stories (20, 40 and 100) and you’ll have to brake them down into chunks smaller or equal to 13.
That is it for the points and the original backlog. If you ever have a new story, compare it to that list to see where it fits (bigger/smaller process) and give it the value of its neighbors.

Phase 3: Velocity & Estimation
To estimate how long it will take you to go through that backlog, do the first sprint planning. Make the total of the points attached to the stories the teams picked and VOILA!, that’s your first velocity measure. You can then divide the total of points in the backlog by that velocity, to know how many sprints will be needed.
That velocity will change and settle in the first 2-3 sprints so it's always good to keep an eye on that value

The small things

I'm optimistic by nature. I can motivate a team of hopeless people by finding the tiniest bit of good in a bad situation. I then proceed into warping reality around that tiny thing until it becomes the only central step. So, for a short time, it turns into the most important part of the work and it creates a new viewpoint (in this case a good one) on the project.

I don't consider this a lie since, like everybody knows, if a lie is a means to an end it becomes a good lie (I like to say that everybody knows that. It makes it alright.). On top of that, since we want to 'do onto others as you would have them do to you' I'm totally okay because I do this to myself all the time.
Yes I do it, I lie to myself every time I attack a big problem and I reach a dead-end. We hear often 'work that big problem by picking at it'. 'Picking' doesn't sound very sexy and interesting all the time. Sometimes you want 'hacking' and 'slashing' because it feels good to move fast and have big results.


Big results. It such a trap since the size or importance of a result is relative. Something which is significant for somebody is noting for an other person. So perspective and mindset is not only important to understand the problem but also to believe in it. You next little task may be the small stone that start the landslide. It doesn't take much to gain momentum in a project and the next task might be the trigger.

Sorry but I don't have a choice, many of my projects are long term monsters barely moving sometimes. You have to appreciate the small things.

What is impossible?

A task is impossible only in the relative point of view of the person describing it as impossible.

Most of the time people come to the conclusion that a task is impossible with this bad induction: "X number of people try to do this and failed. This task must then be impossible."


To me, complex problems are like mountains: Most people attack them head first in a straight line using known and proven methods. Personally, I prefer walking around it and see it from the other angles. Nature as a tendency of creating natural steps here and there. There's nothing worst than reaching the top only to find the ski lift that was on the other face.

Floating on technology

Looking at four teenagers at the mall on a school day made me think.


The masses in north America have a cellphone, an ipod, are using Twitter and FaceBook. On the other hand, they couldn't make a simple HTML page from scratch, explain how the Internet works or tell the difference between a content-driven web page and a blog. “It just works man. What's your problem?” People forgot the basic things, like work, questioning, reading or learning a new thing so your brain doesn't die. I thought technology was supposed to push us further and faster. Looking around, it seems we're sitting down in our big technology lazyboy.

At the same time, the new generations in Asia are rising to build themselves a future. They want to learn and thus they learn fast. They fight for a chance at education and value it. Not only are they using technology but they understand it from the ground up. We should too. Once we'll completely rely on somebody else so we can 'float' on technology we'll be in trouble.

I don't think that everybody must learn all the subtle details, but our society as a whole must continue to understand and respect what is holding our life's comforts.

Creative Programming

Some time ago, I was asked to give a presentation about Creativity At Work. This was part of a series of presentations where people from different fields were asked to give there view on creativity. I wasn't very shocked (but a bit sad) to find out that most of the speakers were visual artists or designers and I was the only programmer. So, holding the fort, I started working on my presentation which mostly revolved around my personal view of creativity and my creation process. All the time, I was expecting some weird comments coming from non-programmers regarding the fact that a 'computer-guy' would have something to say about creativity but, to my surprise, most of the sarcasms came from other programmers. That'll teach me not to watch my back. Apparently, for some coders, no creativity was involved or needed when programming...

I was baffled, because I see coding as a medium. I use it to create, the same way I use paint or clay. I then decided to spend a good part of that presentation demystifying coding and showing it for what it really is: just another tool. Now, it's one of my favorite presentation to give. I love the reactions I get out of it.


Why would a person sitting at a piano be closer to creativity than a programmer at is keyboard? Playing the piano is pretty hard an not that many people can master it. But if they do, it can be used to invent and break new barriers. For me coding can be used that way too, whether the output is music, image, video, robotics or anything else that can be experienced by other people.

#define JAZZ printf(“Do de do, de do wha!\n”);

Points vs Hours

The pains of task estimation. It makes that warm feeling of starting a new project disappear completely. No matter what's your method, Waterfall or Agile, you have to tackle that features list at the beginning of the project and estimate like there's no tomorrow. It's always too big and all those estimations will enable the team to scope. And so, you get to it. It take all of your team days to get through it and a the same time you know you'll have to re-estimate all of those features throughout the entire project.

I got tired of that. Not fast enough, but after 16 years of estimating with hours I couldn't face another project like that. That's when I gave a good try to the Story Points system. It appeared a bit suspicious so I 'googled' away on the subject. My goal was to find THE reason that would convince any programmers on my team to switch to a points estimation. Lucky me, I found one and here it is:

Behold the one reason to use points over hours when estimating.
>> If you show two different features to two programmers, chances are they will not agree on how long, in time, it would take to code it. They will, on the other hand, always agree on which task is bigger than the other one. <<

It takes us now 2-4 hours to estimate what took us a full week before. Here are the easy steps:
1) Put all the possible stories in a spreadsheet.
2) Create a second spreadsheet that will contain, in the end, your estimated backlog (aka the list).
* In this list, the big stories will be at the top and the small ones at the bottom.
3) Copy the first story into the list. Since it's the first item, just drop it at the top of the sheet.
4) Copy the next story into the list by doing an insertion sort based on the simple question “Is this new story smaller or bigger?”.
5) Repeat step four for all the stories.
6) Giving points to the stories starting at the bottom of the list, by giving the first one 1 point.
7) Using the Poker Planning scale (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100), ask yourself if the story above the last one is in the same scale.
* If it is: Give it the same estimate.
* If it's bigger: Give it the next increment in the scale.
* If it's smaller: Move it down until it fits.
8) Repeat step 7 for the entire list.

Tips:
- Try to make most of the list fit between the included values 1 and 13.
- Sometimes micro stories are at the bottom of the list. Give them the value ½.
- At the top you will probably find some Epics of values 20, 40 and even 100. those will have to be broken down into sub stories latter.

Those stories will never have to be re-estimated unless the descriptions changes dramatically. The velocity of the team can be calculated by the total of points they can burn in one sprint and that velocity normally stabilize after 2-3 sprints. With that value you can also predict how many sprints it will take to complete the backlog.

Go points!

Precise imprecision

Have you ever thought about how many types of intersections exist for two lines? Just two straight lines, either in 2D or 3D, bounded by two points (not infinite). And only counting the intersections that fall on one of the two lines, including their end points. You probably didn't, because it sounds pointless.


Well, I had to think about that one seriously while working on a problem back in 2001. It looks simple at first. You start imagining the type of intersections:

• The two lines crossing in the middle


• One end of a line touching the other one


• One end of both lines touching each other

Then you think about that one:

• The two lines completely overlapping

And that gets you to:

• The two lines partly overlapping
  
• And both overlapping combinations with a short and a long line...

In that completed list, you arrive at 7 types of intersections. That would be OK in a perfect world where everything is on a nice grid and points are either on or off the line.
In the real world, lines don't fall perfectly on each other. Many times, two points will be really, really, really close but not touching. That's when you start working with an allowance for imprecision. Doing that, you round up numbers for which the difference is smaller than the allowed precision. So in a 3D world, you would consider two points that are close enough together as one point. This then creates a perfect world with 7 types of intersections... or does it?

Not really, if you're picky like me. Because, with this approach, the data changes with each correction created by the precision rounding. So I asked myself: what would happened if I didn't move the rounded points? What kind of intersection types would that create? After a lot of work, I finished a new list of intersection types. Starting with the original 7 types of intersections, I identified variations for almost each of them. And because of the imprecision allowance, I also found a whole set of sub-cases with each of them acting as a multiplication factor on the base types. This brought the grand total to 129 types of intersections.

129, Ouch!

So, next time you think something is simple... think twice.

Explorer or Poet?

Have you ever worked in companies that apply every year for Canada RS&DE? I have... many times. Over the last 16 years a clear pattern was always present. It is my belief that people applying for R&D credits fall in one of the two following categories: Explorers or Poets.

Explorer: Sees his home as a port from which he comes and goes, because the real action is out their. Thrives in finding new physical things before anybody. Is never afraid of failing and so, is always trying again and again.
Poet: Loves the security of home. Can sometimes go as far as the park in front of his home or even the cafe two blocks away. Excels at seeing things from a new angle. Is so alarmed by the idea of failure that, most of the time, he will extract new views from things he knows.

An Explorer-type company works with the uncertainties of experimentation all year long. At the end of the year, their R&D report is already filed with real research and they can go about their normal business.
On the other hand, the Poet-type company reheated last years stuff to capitalize as much as possible on existing technologies. At the end of the year though, the R&D report is empty. That's when the Poet enters the scene.

Oh dear Poet, can you write me something beautiful, inspired by this everyday stuff?

Make it sound new, I hope I'll get 60% of my reclamation.

Sigh!

Machine Reading

A Machine Reading system would be able to parse any documents and extract all the info, like people, places, time line, any associations between those things and more. It would also have to understand innuendos, ambiguities, sarcasms and backwards logic to understand the real meaning of a text. It would be nice for many application domains like book publishing, web search, forums policing or spying.

Are you nervous now?

A program like that doesn't exist right now. This looks to me like a perfect NP-complete problem. My guess is that it's worth a PhD at the very least... But for that you have to be able to publish your results. Why is that relevant? Because, it looks like the first application of that type is not going to be from the private sector but from the military. Yes, DARPA just gave a 5 year contract of nearly 30 million dollars to BBN Technologies to 'build a prototype' of a fully functional machine reading AI.
Oh, and yes you will need a security clearance to work on the project.

How about now?



For my part, I wish Goolge was building a thing like that and would make it an Open Patent. I also wish I was working on the project but that's another story.

Error handling with the user

One of my development strategy for software tools is to always give a result and working in cooperation with the user. Here are my three basic rules:
1.Software must always output some result
2.Communications with the user must be done by using the current data format
3.Errors must be clearly identifiable compared to normal outputs

Rule #1) Software must always output some result
Software should never just stop. If a minima is reached, a meaningful descriptive of the problem should always be displayed. If an algorithm fails halfway through execution, that first half should be displayed. Why is that important? Because the point at which it stopped is the biggest clue you'll ever give to the user on 'why it failed' and it's the biggest lead for the user on 'how to fix his inputs'. It is of course imperative that those errors outputs are non-destructive to the rest of the data.

Rule #2) Communications with the user must be done by using the current data format
Why use a different language than the one utilized by the user? Imagine that a problem occurs when doing some calculation base on vector data in 3DS Max (a 3D modeling software). Lets say that the problem lies in one of the vertices (points). Your code is trying to process the problematic vertex but it can't. Why? There's about as many reasons that there is users and 3DS drawings, so forget the reason. Of course if you just display a text box trying to describe the problem, it might have a chance at helping the user. But if you highlight the problematic vertex and pan/zoom to it, now that's helping the user. You don't have to do this in the original file. You can use a separate file but keep a similar medium. If the user is doing vector graphics use vector graphics.

Rule #3) Errors must be clearly identifiable compared to normal outputs
Highlight the errors and the thing that you're not sure about. An errors as to be flagrant, make it bold and use red a lot. The user should be able in one glance to identify the problems but still recognizer the surrounding data. This ability to see the bad data in its real context is the key for the user to quickly see the problem.

A good example of this way of working is MS Words handling of typos. While you type, it highlights errors but never stops your actions. You can then fix the problem(s) whenever you want and they're easy to fix because they're in context.

Agile - step 1

In the past, I had some small management experiences, though at the time I thought they were significant. Sure it was easy, I only had to manage autonomous people (See previous post about Planing & Foresight for my definition of autonomous). So as a manager, my real challenge began when I was faced with a team largely composed of young graduates. Some of them were dependent some were autonomous.
In the months before the project started, I prepared myself for this leadership position by reading a lot about the subject. I was convinced to try Agile, or more precisely Scrum. Why? Because one of my previous colleagues was using it for years and swore by it. He gave me some key words like 'Scrum' and 'Ken Schwaber' and I was off, learning about Agile planning, development & management.

We started small with agile. I told my guys we would have a scrum meeting every morning and that we would do 4-week sprints. We set our goals for the first sprint and that was it, our first agile iteration was started. We only did two sprints with a duration of 4-weeks. It was a good length at the beginning because we had to set a lot of basic code and procedures. Later they would be 2-weeks sprints. Also, at that time, we did not have many requirements from our owner.

Owner?

The fact was we didn't have an official owner because we were the only ones using agile and nobody else wanted to participate. So I created a virtual owner in my head. His requirements were derived from the needs of the people I identified as The-people-who-should-be-the-owner and I created my own backlog using Jira. We had no way to calculate our velocity but I documented the results of all the sprints on a wiki page that was shared with the team.

I also had two computer screens setup in plain view on which I had a hand-made manually-updated Excel spreadsheet displaying our sprint burn-down and the status of each task. Yes manually-updated, now is that commitment or what? After some time my people started meeting spontaneously in front of the screens to discuss current problems.

When thas project started people were not accustomed to self-organized team work. But I remember the first day I saw 3 people standing up at a workstation, talking lively and pointing at the computer screen. They were discussing possible ways of solving a problem and planning their work. That was a good sign!

Planning & Foresight

In my opinion, other than the capability of doing their job, the most important skills employees must have or acquire are Planning & Foresight. The most basic of the two is Planning and without it the employees are not functional. This is my 'non-P.C.' scale using Planning & Foresight as the metrics:

Dead weight: Can't plan, Can't foresee anything
Dependent: Plan at task level (actions), Rarely foresees
Autonomous: Plan at module level (tactics), Foresees with little inter-dependencies
Leader: Plan at macro level (strategy), Foresees with inter-dependencies

This is a linear way of comparing the two skills because planning skills depend on foresight. i.e. A good planner cannot be a great planner without foresight but somebody can have great foresight with little planning skills.

After you're done with your list: 1) I take it as a failure of management to either hire a person who is not qualified or failing at motivating that person through work. If you're stuck with a dead weight, let that person go. But wait, you are not done yet. Find out why 'you' (as a person or as a management team) failed so 'you' can prevent it in the future. 2) Create a good environment around the dependent people. Put positive pressure on them to see if they will grow into dead weight or autonomous people. 3) Keep your autonomous people challenged and encourage leadership in them. 4) Don't forget your leaders. Most of the time they're doing fine, but sometimes they

need to vent or to know they're doing a good job.

Note: I'm pretty sure there is a parallel between this way of sorting people and the 'Ability & Willingness' four-quadrant[1] table I recently heard about. I'll post about that later.

References
1. Don Phillips, 2007, The four-quadrant leadership team