Infrared on the cheap

When you make mobile robots, infrared detectors are a must. Here's a nice specimen taken in the Internet wilderness:


The problem is the cost. Starting at $13.95 US plus tax, plus shipping from Mars and the retarded Canadian border fees... in the end, it's to much. Not only that! It takes two weeks to come here. Two week! Are they using camels? I'm living in Quebec city, it's not that small, we even have asphalt and electricity.

Deep breath

Anyway for about $2.50 you can make the 'same' thing at home with these components:

• Detector $1.95
• Light $0.32
• Resistor (220 ohms) ~$0.15
• Bit of PCB board ~$0.01

Long live DIY

AMD's backyard

Blackberry is not the only company having a bad year, AMD is also having hiccups.


A tile just fell on AMD. It just canceled the production of the 28nm Bobcat processor. This news by itself is extremely bad for the company but this is not the only tile. In fact maybe the entire roof is caving in.

Around October AMD released is new Bulldozer chip. It was supposed to be their flag ship unlike the Bobcat which targets the mobile platform. A basic design decision in the Bulldozer chip makes it less effective.

During that time, on the server front, AMD is trying to push the use of its Fusion-Cloud (sadly based on the Bulldozer core). That effort is taking off like a concrete rocket while ARM based servers are in orbit. Yes, ARM, not in portable devices but in servers. They teamed up with Calxeda and mighty HP to start a new server technology.


While ARM is on the subject. AMD is not going anywhere on the mobile front either. Guess what's in your iPhone, Nexus, Galaxy or Blackberry? ARM of course.

C'mon AMD, get up and fight.

Trans-App / a bleep on the radar

A Facebook phone build on a mix of Android software & hardware optimize for Facebook-type features. Could this be the first real Trans-Application device? Like I mention in this original Trans-App post, the idea that devices would have to adapt to applications needs could become a reality.

To clarify the concept of Trans-Application I should say that Trans-App devices must be designed around constraints dictated by two or more applications. If this new Android-Facebook phone supports more than Facebook, it's well on its way to be a Trans-App device.

Why is this important? Because nobody will want to carry a Facebook phone and a LinkedIn phone and a Google Wallet phone. We want things to be integrated into one device. And while we're at it we want that device to fit in our pocket and have an 8 inch screen and.. um.. you know what I mean 'cause you want it too.

Purchase may soon be driven by the preference of devices optimizing the user experience of the favorite applications. Not by the OS. Not by the Browser. Not by the hardware brand.

Sunday night with Bluetooth

What do you do after installing your Christmas lights? Build a robot of course!


This projects started with a modified version of the Boe-Bot on which I added big dirt wheels scavenged from a dead RC car. The simple structure on top is made with my usual LEGO spider-legs system supporting the Arduino and its proto shield. I'm using the Sparfun proto shield since it has a build-in connector for the BlueSmirf Bluetooth breakout board and.. it's red. I also use two power supplies to separate the servos from the rest of the electronics.

Software wise, I used the Sena BTerm app to do some direct communication with the Bluetooth device. This app was very practical since it enabled me to only code on the Arduino side. This made prototyping very fast. The only real work began when I had to make the real Android app using Bluetooth. For that I hacked Google's BluetoothChat demo and after a short time I was using buttons and sliders to communicate with my Arduino. Why was that work? Eclipse...


A great advantage of using an Android device as the communication platform is the real-time outputs. This is very nice when debugging since you don't have to be tether with the laptop.

Edit 1: I later created an Arduino to Arduino link with bluetooth.

Edit 2: Here is similar code a later used for the minirccar

11.11.11 11:11:11

When the world ends...

Trans-Application

In the last 10 years, with the rise of Apple devices and the mobile movement, applications must be cross-platform to survive. But lately, with Android or the Chrome browser, we see a new trend emerging where devices are created to be compatible with specific OS or applications. I call this Trans-Application.


I figured, we're already using the cross-platform, cross-device and cross-console when we refer to software compatibility, now we need a prefix for device compatibility.

Applications are gaining more and more power. Getting to FaceBook is more important than the way you get to it. Would you be surprised if there was a FaceBook tablet? It's not that crazy since 10 years ago people would have laughed at you if you had mention the possibility of a Chrome Book laptop.

Devices will soon have to conform to more than OS demands but probably to applications demands.


Trans-Application... or maybe Trans-App.

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!