During my time at Microsoft Research Cambridge earlier this year, I designed and implemented a simple light seeking robot with .NET Gadgeteer and some Tamyia parts.
Mike Dodaro kindly documented the process and you can check it out in the Gadgeteer blog.
.NET Gadgeteer light seeking robot
When I visited Rio this February, I managed to run two .NET Gadgeteer workshops.
The first one was at the Superior School of Design @ Rio de Janeiro State University, and counted with almost 30 participants.
ESDI Workshop
Prototype built by some participants in the workshop
The second workshop was aimed at first year Computer Science and Engineering students and took place at the Informatics Department @ Pontifical Catholic University of Rio de Janeiro.
Participants building a digital camera with .NET Gadgeteer
The experience of running these workshops was great and I hope to be able to do it again in the future. I would like to thank all participants, everyone that helped me organize the sessions (special thanks to Dr. Denise Filippo, Dr. Hugo Fuks, Wallace Ugulino and Gabriel Barros), ESDI-UERJ, DI-PUC-Rio, and the guys at Microsoft Research Cambridge that kindly lent the necessary equipment.
Today I tested the GHI Music Module. Even though the driver that ships with the SDK does not support FileStreams, Mischa Boender has extended the driver to provide this functionality.
GHI Music Module
I recommend checking out Mike Dodaro’s tutorial on how to use it.
I managed to load a a song into an SD Card and listen to it using the module and even though the song didn’t play very smoothly in the beginning, after I disconnected the USB cable from my computer, it played rather well.
In this tutorial, I am going to demonstrate how to make two devices built using the .NET Gadgeteer technology talk to each other using the Bluetooth protocol. For this, we are going to need:
- 2 x FEZ Spider Main Boards (it should work with other boards too, but I am using the FEZ Spider)
- 2 x USB Client DP (again, any other power board should work as well)
- 2 x GHI Bluetooth modules
- 2 x Button modules
- 1 x Light Sense module (or the sensor of your choice)
- 1 x Multicolor LED module (or the output media of your choice)
Our network is really simple. One of the modules will play the part of a host or master while the other will be the client or slave. The message exchange will work in the following way:
- The client makes itself available for discovery
- The host inquires the available devices
- Once the host finds the client, it connects to it
- After the connection is established, the client starts to stream data to the host.
We are going to use this network to stream the data from the light sensor to another module, which will control the colour of an LED accordingly:
- Green – No data is being transmitted
- Blue – Minimum light
- Red – Maximum light
- Between Blue and Red – Different light levels
The circuit diagram for the client is the following:
Circuit diagram for the client
However, because the current released driver for the Bluetooth module is still in its alpha stage, we are not going to add the Bluetooth module in the circuit designer. Instead, we are going to use the driver that I developed, which can be downloaded at: https://gadgeteerbluetooth.codeplex.com/
The code for the client can be found here.
Basically, when the button is pressed, the BT module becomes available for pairing.
void button_ButtonPressed(Button sender, Button.ButtonState state)
{
client.EnterPairingMode();
}
Once the host finds it and makes a connection, it will raise the BluetoothStateChanged event. Then, it will check if the new state is a connection and if so, will start the timer.
void bluetooth_BluetoothStateChanged(Bluetooth sender, Bluetooth.BluetoothState btState)
{
if (btState == Bluetooth.BluetoothState.Connected)
{
timer.Start();
}
else
{
timer.Stop();
}
}
The timer will then raise the Tick event twice every second, and in this event’s handler, we will stream the data to the host. I also added a frame to the data, so the host will know that this data regards the light sensor.
void timer_Tick(GT.Timer timer)
{
client.Send("LIGHT=<" + lightSensor.ReadLightSensorPercentage()+">");
}
The circuit for the host is the following:
Circuit diagram for the host
Again, instead of using the GHI driver, we will use the one that I implemented.
The code for the host can be found here.
When the button is pressed, the module will start searching for devices. Each time it finds a device, it raises the DeviceInquired event. In this event’s handler, we will look for the device that we want. In my case, the device was called seeedstudio, but you should change this line to match your device’s name. When it finds the device it is looking for, it tries to make a connection using its MAC address (an address that is unique to the device).
void bluetooth_DeviceInquired(Bluetooth sender, string macAddress, string name)
{
if (name.IndexOf("seeedstudio") > -1)
{
Debug.Print("Connecting to: " + name);
host.Connect(macAddress);
}
}
As we saw in the last section, when a connection is established, the client will start streaming data. This is handled in the DataReceived event handler. Basically, in this method, we check whether the data contains “LIGHT=<” (the frame of the data frame that we created) and if it does it will parse the data (which is a percentage of brightness) and will apply this percentage to the red and blue values of the LED. If the data was not related to the light sensor, the LED will turn green.
void bluetooth_DataReceived(Bluetooth sender, string data)
{
//Debug.Print("Received: " + data);
if (data.IndexOf("LIGHT") > -1)
{
string cmd = "LIGHT=<";
int first = data.IndexOf(cmd) + cmd.Length;
int last = data.IndexOf(">");
double value = double.Parse(data.Substring(first, last - first)) / 100;
//Debug.Print("V:" + value);
led.SetGreenIntensity(0);
led.SetRedIntensity((byte)(value * 255));
led.SetBlueIntensity((byte)(255 - value * 255));
}
else
{
led.TurnGreen();
}
}
After loading the code separately to each board, turning both boards on and pressing the button on each, you should start seeing the LED change colour when you cover/uncover the light sensor.
In this tutorial, we demonstrated how to stream sensor data over Bluetooth in order to control the colour of an LED. This example could be extended to transmit data from several sensors and even transmit data back from the host to the client.
If you end up using this tutorial to make something cool or if you have any questions, please let me know.:
I’ve implemented some Beta drivers for the GHI Bluetooth Module.
GHI Bluetooth Module
The source code can be found at https://gadgeteerbluetooth.codeplex.com/
Any comments are welcome!
As my first collaboration to the .NET Gadgeteer project, I am writing the drivers for the Seeed Studio Cellular Radio Module. This board ships with a SIMCOM SIM900 cellular engine. It required a lot of patience and work, so I am going to share some advice if you ever find yourself in a similar project. I will make the driver available for download in a near future.
Microsoft Research really made our lives easier in this step. Their builder template (available here) is really self explanatory. I also recommend reading the builder guide to make sure your code adhere to the Gadgeteer specifications.
One the first steps I took when I started to implement the drivers was look online for similar projects. I found the drivers for a SIM900 GSM/GPRS shield for Arduino and started to implement my drivers in a similar fashion, only to discover that this wasn’t the best way to implement the Gadgeteer drivers.
Arduino code runs in a while(true) loop indefinitely and these drivers use this assumption. Gadgeteer code, however, is event-driven. In fact, because of that you aren’t even supposed to use while(true) loops in your application code (see why in this post by Kerry Hammil).
After learning this the hard way, I had to restart from scratch and indeed the code runs much better.
This is a really boring step, but it is crucial for the success of the project. The documentation for the SIM900 commands is almost 200 pages long and every bit of it ended up being relevant. Understand well the capabilities of the module, especially the syntax of the commands. Whilst browsing online forums I found loads of people having trouble with operations like making a voice call just because they were missing a semicolon in the end of the command.
One of the biggest challenges I faced was parsing the responses from the module. The documentation states that each response is separated by <CR><LF> characters (carriage return and new line), but these are characters that can also be found elsewhere in messages. Turning on the echo helps.
Because the drivers are asynchronous, the API works in the following fashion. The user requests an operation from the module and the drivers send the corresponding command. In a separate thread, the drivers are listening for incoming responses from the module. When it detects that the response for an operation has arrived, they raise the corresponding event. By assigning a handler to that event the user processes that response.
To test this, I would follow the same procedure for every command:
When developing embedded systems, there are many variables that might be cause of error. In this case, it could be the main board, the module, the computer, the driver, the application, the SIM card, and so on… Therefore, it is important to narrow down those variables to make sure you are looking for errors in the right place. It took me a while to figure out why my voice calls methods weren’t working until I discovered that the SIM card that I was using didn’t make phone calls…
Also, this is a very power consuming module. I read online that it can draw up to 2A of current, so the USB port in your computer might not be enough, especially if you are also using power demanding modules like the LCD display.
Sometimes, when you send one command after the other without giving the module enough time to process them, the module doesn’t respond, so make sure to add a few Thread.Sleep() lines to your code, especially if you are using a multi-threaded design like myself.
This week I started working with the Microsoft .NET Gadgeteer. Being an Arduino fan and a C# programmer, I was delighted to see Microsoft bringing an open source prototyping tool to the market. It was developed at Microsoft Research Cambridge as a tool to support their own projects, in order to design and build new devices very quickly.
Prototype built with .NET Gadgeteer
The hardware platform is completely solderless, so building a circuit is just a matter of plugging a few modules together with ribbon cables . The programming is done in C# using Visual Studio, so you can leverage all of its building and debugging tools to develop embedded systems. Then, you can use their Solid Works plugin to design the enclosure and print it with a 3D printer or cut it with a laser cutter and you’ve got a new device in your hands.
.NET Gadgeteer is an open-source tool, so Microsoft is not actually selling any boards. If you want a kit, you can currently get one from GHI, Sytech or Seeed. It is more expensive than Arduino (a FEZ Spider main board costs around $120 vs. $30 for an Arduino Uno) , but it is a lot more powerful (it has got a 72MHz. 32-bit ARM7 processor) and it is easier to program. But the main selling point for me is indeed the speed in which you can prototype devices. In a matter of minutes you can have a working prototype.
If you want to get started, here are some good starting points:
.NET Gadgeteer Website
Pete Brown’s Introduction to Gadgeteer
Mike Dodaro’s Gadgeteer Posts
