Explorations in Technology

Over the past few months I have been working on a project, dubbed the “Smart Light”, that allows a user to control a connected appliance based on the ambient light in a room. I decided to gift this to the person who requested it so I put the final touches on it just after Christmas. With the hardest part over, installation and tuning were a breeze and I’m excited to take what I’ve learned from this project and build on it.

I made only a few minor changes but, overall, not much has changed since my last update. I had to replace the AC/DC converter I was using to power the Trinket as it failed on me. I’ve discovered that quite a few old dumb-phone chargers output 5V and varying mAh so I’ve begun a collection of name brand chargers for future projects like this. As you can see from the picture, I mounted the analogue light sensor inside the smallest Hammond case I could find at a local electrical supply shop. I braided the 3 wires to the sensor so that it would be easy to work with when installing the system. Also, I recently discovered heat shrink with hotmelt glue and used it extensively in this project as there were a number of exposed connections that normal heat shrink couldn’t handle.

With the project installed and working, I’m quite happy how it turned out but I do intend to make changes in both the hardware and software for the next version. The sketch for this project is simple and boils down to: if the light value is below a specific value, activate the relay else do nothing. The problem with this logic is that the light values fluctuate so that the value read by the sensor may jump above and below the threshold value. This jumping leads to the relay putting on a light show as it is rapidly activated and deactivated. To fix this, I am going to have the system activate the relay only after a certain number of readings in a row are below the threshold. This should drastically reduce the flickering effect when the appropriate value is found.

On the hardware side, my main concerns are minimizing the size of the system, adding the ability to adjust the threshold value that determines when to activate the relay and adding flexibility in placing the sensor. The biggest use of space in the case is the wiring so for my next version I’d like to move as much of the wiring and components to PCB. Right now, the only way to adjust the threshold value for the system is to modify the whole sketch and then re-upload it to the system. This is hardly ideal so I’d like to add a knob or series of buttons that allow the user to change the value. I’d even go so far as to add a small LCD screen to allow the user to set custom values and to see what the value. Lastly, I’d like to investigate the cost of making the sensor wireless so that the user isn’t limited by the length of the sensor wires when installing the system. Make the sensor wireless also opens the door to expanding the system to include other types of sensor allowing for further automation and monitoring of the home. I could see motion sensors being added to the system to trigger a security camera.

As part of my ongoing rover project, I have started writing C++ libraries for the various sensors and actuators. The first device I have begun to tackle writing a library for is the Adafruit 10DOF sensor. This sensor has libraries available for Arduino boards and in Python. Writing library code for the sensor hasn’t been without issues but has been a great learning experience. There are a lots of online tutorials but I have found that Derek Molloy’s tutorials have been consistently helpful. I recently bought Derek Molloy’s book Exploring BeagleBone: Tools and Techniques for Building with Embedded Linux to aid me in working with the BeagleBone Black. I did so because I found his freely available tutorials extremely thorough and have had the most success following them compared to other material online. His book includes the material in his tutorials plus more including introductory topics such as administering Linux and basic electronic components to advanced topics such as interacting with the onboard Programmable Real-time Units (PRUs).

To start writing the driver for the 10DOF, I focused on one sensor at a time. I took the Arduino code for each sensor provided by Adafruit and went about replacing all calls to the Wire library to appropriate calls to the libmraa library. The 10DOF sensor uses the I2C bus to communicate with all the sensors and, initially, I used Derek Molloy’s I2CDevice class to handle communication. After some success with this class, I decided to use Intel’s libmraa for handling all communication between the BeagleBone Black and peripherals. I made this switch because Molloy’s class is not as complete as libmraa and only deals with I2C communication whereas the libmraa api includes SPI, GPIO, UART and PWM functionality. This means I can use libmraa for controlling the motors and other sensors instead of having to write my own code or relying on separate libraries for sensors using different communication interfaces.

Writing the driver for each sensor was not as simple as replacing some functions in the Arduino code. The datatypes in the Arduino code had to be changed to match those recognized by the g++ compiler while staying true to the datatype used to store the data in the sensor’s registers. This required a close reading of each sensor’s data sheet to make sure I was storing the register data in variables with the same datatype. I won’t go into fine detail as to what changes I made since you can see the code yourself and compare it to the original Adafruit Arduino code.

There were a few times while working with the 10DOF sensor when I lost connection to it. This can occur when a register on a sensor is mishandled causing the sensor lock up becoming unresponsive. To deal with these lock ups when working remotely, I wired a P2N2222 transistor into the 10DOF sensor circuit so that I could power cycle the sensor if it became unresponsive. This has happened a couple of times while developing the driver software. I’ve been careful to make sure I’m properly working with the registers but mistakes still happen. Thankfully no damage was done and I haven’t needed to use this feature yet.

I’m still working on the driver and will post another update when it’s completed. The code for the BMP180, L3GD20 and LSM303 sensors can be found on my github page. Just make sure you have the libmraa library installed on your BeagleBone Black. This code is still under development and is provided with no warranty so use it at your own risk. If you have any comments on the code, please use the github issues page. My plan is to roll these separate libraries into one library for use with the 10DOF sensor but I will keep the repos for each sensor for those who buy the sensors individually.

Over the last few months I have made a concerted effort to develop my embedded systems skills by starting projects such as my Smart Light or Rover. As these projects ramped up, it became clear that I needed an easy to use, accessible and flexible project management solution. I was using text documents and spreadsheets before I started my search but these tools are clumsy and don’t scale well to smartphones.

Early in my search I discovered tools like Asana, Todoist, and Azendoo which all looked promising. Asana and Azendoo are very similar in allowing you to create projects with lists of tasks (which can include detailed descriptions, subtasks, attachments and comments). Projects can be shared with other users for them to edit. I tried Azendoo first and gave it the closest look compared to Asana. I really like Azendoo and started managing my projects with it but I had some difficulty getting it to work with my Motorola X. There were a few times when I tried to add tasks to a project but when I went to fill in the task info my inputs were not recognized. Also, as much as Asana and Azendoo are very capable, I found that the long list of tasks did not make it easy to see what tasks were done, in progress or not started. I’m sure there are ways to set this up but I suspect this would be achieved by labeling or colouring tasks in the list.

This slideshow requires JavaScript.

I finally settled on a solution when I came across Trello. Trello allows you to manage tasks visually using cards similar to how one might use sticky notes on a board. This is great if you’re visually inclined and prefer diagrams and charts over text. A card in Trello is analogous to a task in Azendoo. Each card can have it’s own detailed description, comments, checklist and comments as well as labels, due dates and stickers. Cards are arranged into groups called lists and lists are organized into boards. Each board can have multiple lists and each list can have multiple cards. The ability to organize cards into separate lists within the same board is the feature that made Trello work for me. Multiple lists allows me to organize tasks by their current progress which makes it easy for me to jump back into working on a project since I don’t have wade through all the tasks to find what is currently in progress.

The other features I appreciate are labels. For my rover project, I divided the functionality up into systems so in Trello I labeled tasks related to a system with a certain colour so I can quickly recognize what system a task belongs to. You can also add stickers to cards but the selection is limited for the free account. If you buy into an upgraded account, you are able to set custom backgrounds for your boards and have access to a better selection of stickers.

I use Trello for both personal and work related projects but also for keeping track of related lists such as gift ideas. I’d strongly recommend it to everyone needing to manage a project or who just needs to keep track of what your family wants for their birthdays! It’s also very easy to share individual boards to specific Trello users or to the public in general. You can view the board I use to manage my rover project here.

When people talk about speed in the world of programming languages, they usually center the discussion around compiled vs interpreted languages. In this post, we will discuss two of the most famous languages on this planet, Python and C. I was recently playing around with this and I made a few pleasant discoveries. So I thought I should share them here. One of the biggest reasons as to why Python is slower than C is because of the dynamic typing feature in Python. While it may be true that dynamically typed programming languages are slower than statically typed languages, it may not be the major factor slowing down your Python code. The dynamic typing feature of programming languages like Python makes the interpreters harder to optimize. I guess this is the cost of having an extremely beginner-friendly language! But one thing to note is that there is a big difference between…

Here is quick update on the progress of my Smart Lamp project I started near the end of the summer. As I mentioned in my previous post, I have already put together a prototype circuit to test controlling the flow of power to a plugged in lamp based on the input of the light sensor. Below is the proposed final circuit for the smart light project. The only change I foresee is the removal of the LED indicator since the Trinket and the AC-DC converter both feature LEDs on them and space is tight in the enclosure.

Smart Lamp Final Circuit

I’ve bought a Hammond ABS enclosure to hold all the components. I removed the mounting stand-offs as they did not match well with any of the components and the relay would not fit if mounted to them. The white board you see in the picture is foam board which I was thinking of using as a medium to mount the parts to. My current plan is the use Velcro to secure the components right to the case. I tested this using my EDtracker build and a small Hammond enclosure and it worked well. The tracker is secure when in the case but can be easily removed if need be. I have included a picture that tries to illustrate how the extension cord will be routed through the enclosure. I still need to drill a hole for the end on the left of the picture.

Smart Lamp in Enclosure

Cable Path

The biggest change since my last post is the addition of a spare USB charger I had. This will serve the purpose of powering the microcontroller right off of the extension cord. I have removed the USB port from the charger and soldered wires where the power pins were in order to keep the USB port on the Trinket free for programming. Unlike the circuit shown above, the trinket is mounted on a (trimmed) proto-board in order to easily allow multiple connections for powering the relay and sensor.

There’s just testing, soldering and calibration left! I’ll post a final build update regarding the testing and calibration with pictures of the final product soon.

We Can Rebuild Him…

After watching The Martian a few weeks ago, I was inspired to create my own semi-autonomous rover. Unfortunately, the privilege of space travel is still reserved for a few select exceptional individuals and even they may only get the chance once or twice. I’d still like to help push humanity towards the stars so towards this end I’d like to develop my skills with embedded electronics which control the probes and craft we use to explore our neighbors. So I decided to redevelop my previous “rover” I called Geoff. In his first form, Geoff was an object avoiding robot built with an Arduino Uno, IR distance sensor and the Dagu Rover 5 chassis.

With this project, my goal is to capture certain aspects of a semi-autonomous rovers like those we’ve sent to Mars. I’m also including features that are characteristic of probes used here at home like direct control. The goals I’ve chosen to focus on are listed:

Prioritized Reactions

Suspend activities and begin charging

Send logged data when threshold reached

Environmental Awareness

Map best route to goals

Reconnaissance using sensors with logging

Energy independence

Solar panels charge on-board batteries.

Remote Access and Control

Software updates

Navigation updates

Direct control

Better than he was before. Better… Stronger… Faster

In selecting the parts for Geoff 2.0, I strove to mimic the functionality of a Mars rover while keeping the price and difficulty within my means. I already have a BeagleBone Black and after some research found that it would be a capable board for this project. Not only does it support various ARM Linux distributions and plenty of GPIOs, it also include two realtime microcontrollers built in called Programmable Realtime Units (PRUs). With these, I can stick with the Debian image that it came with without patching the kernel or replacing it with a real time kernel. I still may move to a real time kernel in the future but that will be implemented later in the interest of quickly setting up the hardware and testing it.

Tentative Parts Listing

BeagleBone Black Rev C running Debian Wheezy (kernel version)

Navigation

Adafruit 10-DOF IMU Breakout – L3GD20H + LSM303 + BMP180

Adafruit Ultimate GPS

Power

2 x USB / DC / Solar Lithium Ion/Polymer charger (v2)

INA219 High Side DC Current Sensor Breakout

2 x Lithium Ion Battery – 3.7v 2000mAh (wired in serial)

UBEC DC/DC Step-Down (Buck) Converter 5V @ 3A

2 x Medium 6V 2W Solar panel (2.0 Watt)

Drive

4 x 7.2V DC motors

4 x Quadrature Encoders

2 x Adafruit TB6612 1.2A DC/Stepper Motor Driver Breakout Board

various sensors

temp and humidity

IR motion

object detection via sonar

CMUCam5 Pixy camera

The first system I have focused on after building the rover’s frame, pictured above, has been the power system. Since I want this rover to be autonomous, I have designed it to be as energy independent as possible. To achieve this, I designed a power system that incorporates LiPo battery packs that can be charged via a solar panel. Implementing and testing the solar component will be done later on in the project since we’re going into winter here in Alberta and because there is a lot of work to be done before the freedom solar panels grant is of any use.

This slideshow requires JavaScript.

Since the drive system will be one of the largest power hogs in the system, I have been working on it in tandem with the power system. The drive subsystem will consist of the four motors and encoders found in Dagu’s Rover 5 chassis. These motor are rated for 7.2V with a stall current of 2.5A and a free run current of 210 mA. As mentioned above, power will come from two 3.7V LiPo batteries wired in serial with a total output of 7.4V. The drive system will be wired in parallel with the rest of the rover. Unregulated power will go the drive system, branching off before the 5V regulator. Regulated power will go to the BeagleBone Black, sensors, and motor drivers. The central power system circuit has been wired up and I’m in the process of creating a simple wiring harness for the motors. Once that is complete, I’ll begin the process of writing programs to test the drive system’s wiring, power drain and capabilities.

I’ll be posting more updates as I continue my work be sure to come back for more soon! Here is a link to the Trello board I’m using to manage the project. I do comment on the tasks as needed and many tasks include checklists to document their stage of completion.

Update History:

11/16/2015: Update power sub-system fritzing diagram to fix errors and reflect changes made to circuit during implementation.

The Kit

I’ve been playing Elite Dangerous since it was released and have been playing similar games for as long as I have been gaming. Since its release, I had wished that I could better utilize the ability to move my player’s head around while flying. It was only a few weeks ago that I heard of EDTracker while reading a post on reddit’s /r/EliteDangerous. EDTracker is exactly what it sounds like: a head tracker for Elite Dangerous. Actually it’s a head tracker that can be used for whatever game allows the use of a joystick to be assigned to head movement. It’s recognized by a PC as a USB joystick. For more details, checkout the EDTracker homepage. You can order parts form the EDTacker page or there is a kit available from hobbycomponents.com. I bought the kit available from hobbycomponents.com featuring the now discontinued 9150 module. The 9150 has been replaced by the 9250. The difference seems to be increased performance while being smaller and using less power than the 9150 module. As you can see from the pricing is that this kit is very cheap for the components included. Similar components from other sites such as Sparkfun will cost you more as of early September 2015. Also, this kit is many times cheaper than other head tracking solutions such as TrackIR. So if you’re willing to put in the work, you can get very accurate head tracking as a fraction of the price.

The Build

building the tracker was not walk in the park since I was going for as compact a build as I could. Thankfully I didn’t have to design the circuit myself. The EDTracker website hosts a guide written by community member Bartybee that outlines how to build the tracker as you see it in the pictures. As you can see, The PCB is cut to size then sandwiched between the Arduino and 9150. Soldering the tracker together in this manner was tedious if your not an expert at soldering. Bartybee’s guide also calls for a very thin gauge wire described as “doll house wire”. The holes on the PCB allow for wire that is no bigger then 17 AWG including the wire’s casing. This wire allowed him to run it through the holes in the PCB. I didn’t have any wire that would fit through the PCB holes so I was forced to make it work with the wires soldered on the top side. This worked fine but it got a little crowed near the end. The wire soldered to the 9150 header didn’t interfere with mounting the 9150. I just made sure the wires were soldered as far down the post as I could without melting the header (too badly!).

I’d suggest buying the pre-made PCB if you’re looking for a cleaner and easier build. I didn’t feel like paying the extra cost so I paid for it in elbow grease! If you choose not buy the premade PCB then make sure you research cutting PCB. I got by with a heavy duty box cutter and patience but a hack saw would be a better choice. Thankfully, all was well once I double checked everything and powered it up for the first time.

The Experience

The tracker is used with a client program that you must download from the EDTracker website. You will also need to download the Arduino drivers from the site but only if you don’t have the Arduino IDE installed already. The drivers allow the PC to recognize the Arduino used in the tracker so that the client can flash it with the firmware they’ve written. I already had the IDE installed so this wasn’t an issue. I had no issues getting the client to recognize the tracker or flashing the firmware. Once that was done, I made sure to watch the calibration video made by the developers which explains how to use the client as well as how to calibrate the tracker. The calibration is very simple but is something that must be done every time the device is powered on. In fact, the tracker spends the first 20 seconds after powering up calibrating so be ready for that before you plug the USB cable in. From there, I booted up Elite and mapped the head look axes (up/down and right/left) with a only a very small deadzone.

With the tracker mapped, I jumped into the game and was quickly blown away by the added immersion that the head tracker added to the experience. The accuracy is great and the tracker is always responsive. I have very few issues with drift and whatever drift that has occurred was due to my poor initial calibration on power up. The only issue I have is mounting it to my head phones as they do not have a solid band but rather two stiff cable supports that connect the ear pads as you can see in the first photo.

I would readily recommend this to anyone who has a flight sim they enjoy even if its only casually. This tracker greatly increases the immersion while gaming so it is easily worth the price. Also, don’t be afraid of putting together yourself as the guide is very complete and there are videos that go through common issues that come up when putting the tracker together. Another thin to keep in mind though is that the tracker is not wireless so you will need a USB cable that is long enough to connect to your PC while allowing you to sit comfortably. I have seen others wrap their headphone and USB cables together to help cut down on the mess of wires. If you can handle the extra cable and the build then you too can bring your favourite flight sim experience to another level!