Communication
Hardware Hurdles and Forwarding Firmware
Three weeks ago, members of the AR groups approached us with the vision of connecting their AR experience with the Arduino, whether it be sending sensory data from the Arduino to influence holograms or sounds, or to send user interactions to the Arduino to actuate lights or motors. As a group, we agreed to explore this connectivity, alongside our own investigations into the kinetic façade. After an initial consultation with Justin, it was suggested that we attempt to use an open source project called the RedBear Duo.
THE REDBEAR DUO
As mentioned, Justin advocated for the use of the RedBear Duo, and the video above seems to show that this is exactly what we’re looking for. Luckily, Justin had one available for us to borrow. After I picked it up, I set about trying to understand it. Loading one of the example files, I wired up the Duo, and compiled the script.
Nothing…
And so, came the retrospectively arduous task of troubleshooting the device.
Attempt 1:
Install the latest board in the Arduino Board Manager. Make sure I was sending data through the correct serial port.
Attempt 2:
Determine the firmware of the RedBear Duo (v.0.2.1) as it was probably acquired a while ago. From there, install correct board in the Arduino Board Manager. It works; however, the version is so outdated, and all the documentation out there on this device only applies to the latest firmware version.
Attempt 3:
Update the firmware of the device using the Arduino IDE. Going onto RedBearLab’s GitHub page, there was a “Firmware Deployment Guide” that goes through the process of updating the device. Following this guide, it was quite clear that it was not going to work through Arduino. Apparently, the firmware that is already in the Duo needs to be of v.0.2.5 or higher. Anything lower and it will not work.
https://github.com/redbear/Duo/blob/master/docs/firmware_deployment_guide.md
Attempt 4:
The other option to update the firmware of the device is through “dfu-util”, which is a command line tool for device firmware upgrade via a USB port. The first step was downloading the software. Moreover, I’d need to append the path of the dfu-util.exe to the system environment variable. This will allow dfu-util to be executed globally in command prompt. It was at this point that I got lost. The next step is to “Get the source code and build it…”
No idea…
Not being able to do this by myself, I enlisted the help of a professional: Justin.
https://github.com/redbear/Duo/blob/master/docs/dfu-util_installation_guide.md
Attempt 5:
One afternoon, we went to Justin’s house and for a few hours, and attempted to fix all the hardware issues we were experiencing (the explorations into the kinetic façade has also been stunted, as the stepper motor was not working). We explained the problems with the Duo and he started to work his magic. We went through the same steps as in “Attempt 4” (with the addition of one step because he was working on a mac), and then some.
“I can understand why you were having issues with it…”
After the copious amount of time invested into the troubleshooting process, Justin told us to leave it with him, along with the stepper motor, and he will get back to us when it was fixed. That was on the 12th of April…
THE PARTICLE PHOTON
As frustrations mount, from group members inside and out, Dom, of the Hololens group took it upon himself to purchase a device known as the Particle Photon, and found great success with it.
“With an immense amount of possibility, The Photon can be used to create commercial sensor networks and smart home projects alike. Quickly and easily build WI-FI connected devices with intuitive development tools.”
Please refer to his Medium post to view his progress:
https://medium.com/code3100/communicating-between-the-iot-and-a-hololens-a3deae772fb0
HARDWARE LIBRARIES [LED STRIP LDP8806]
Having witnessed Dom’s accomplishments with the Photon, I decided it was my duty to purchase one of my own, and complete what was expected of me. Once I placed the order, I set about to try and understand the differences in the Arduino IDE and the Particle IDE, so that I am ready whenever the hardware arrives. Several insignificant differences later, I came across something that stumped me.
When receiving data from the Hololens to the Arduino, we intend to take that data and control either an LED strip, or the motor for the kinetic façade. In the case of the LED strip, a specific library, created by the people that developed it, is needed for the hardware to understand your code. The way the Particle IDE works, is that it is all in your web browser. The most popular Arduino libraries are available to use through their built-in library search; however, the lesser known libraries aren’t as lucky. (I believe that there are methods to include private libraries onto the Particle IDE, however, I did not want to explore that until I have confirmation from Justin that it can be done). This sparked the need to explore other methods of wireless communication that allows us to use this specific LED strip, and other hardware that have lesser known libraries.
HTTP REQUESTS & SERIAL COMMUNICATION
After discussions with Dom, I understood that all the Particle Photon is doing to receive information form the web, is via something called a HTTP request. A Hypertext Transfer Protocol (HTTP) request can be broken up into either a POST request, which is sending data up to the web, or a GET request, which is the opposite. The latter sounded awfully familiar to something that I worked on in the past, and that something used a program called “Processing.”
Processing is a flexible software sketchbook and a method to code in the context of visual arts. Within Processing, there is a function called “loadStrings()”. If you insert either a file or URL into the brackets, this function acts as a GET request. I wrote a simple Processing script that allows us to view the code in the Processing console.
Because we intend to request live data from the Hololens, I then wanted to test the delay from when something occurred on the web, to when the Processing script will receive it. I figured the simplest way to do so is through an online clock. There is this website called “time.is” which is contains a Unix Clock (total seconds counting upward since 00:00:00 1st January 1970). I wrote a Processing script that asks this website for the Unix time, and displayed it in the Processing sketch.
Proving that Processing can pull almost-live information from the web, next on the agenda was to connect this Processing script to the Arduino IDE, which contains the applicable library to control the LED strip. The method explored was called serial communication, which is the process of sending data from the PC to the Arduino via a USB port. There is a further delay by using this method, so I am currently testing procedures to reduce this latency.
