Development & Testing

To realise our project we first set about choosing the technology that we would use. To allow us to do this effectively we first identified the functionality that our project requires in order to make more informed decisions on technology.

We also put together a conceptual 3D model of what the product could potentially look like if put into production. This helped us to imagine what the project should look like at the end and provided us with something that each member of the group could aim towards.

Hardware

150802_Particle-26_largeThe first requirement we identified was that of network connectivity. We needed the Coolbox to communicate across the internet in order to access the user’s social media accounts so that it could invite the user’s friends over for a party and broadcast to the world the fact that the user was drinking alcohol alone. For this we looked for hardware with built-in network connectivity. The first device that we considered was the Arduino with WiFi or Bluetooth shield, but having experienced difficulty with this technology in the past we decided to look for an alternative. Thankfully, in a workshop we had as part of the course we looked at the use of a more modern microcontroller with built-in WiFi, the Particle Photon. We decided upon the Photon because of its inbuilt network connectivity, the quality of its online documentation, and the fact that it can be programmed remotely from a browser-based IDE in familiar Arduino code – removing the need for the Particle to be constantly connected to a desktop device via USB.

08958-03-LFor motion detection, we initially aimed to use an infrared proximity sensor. However, we were unable to get a hold of one in a reasonable time frame. We therefore researched alternatives, and initially decided to experiment with creating our own. Using an IR LED with a 900nm wavelength and an IR Photoresistor delicate in the region of 940nm, we expected to be able to detect infrared photons emitted by the LED reflecting off a surface and back into the photoresistor. However, we were unable to reliably detect any kind of reflection, so we abandoned the experiment in favour of a different method altogether.

hcsr04_hiresInstead of infrared proximity detection, we instead moved to using an ultrasonic HC SR04 ranging module, that is capable of detecting an object passing up to 2 metres in front of it, more than enough range for our needs.

The final requirement, light detection, was much more simple than the other two and was very easy to set up. We simply used a visible light Photoresistor that was capable of detecting light at a range of intensities, with a resistor that gave us the best range from 0 for complete darkness and ~4000 in the Photon’s analog range when shining a torch directly onto the LDR.

We were also experimenting with using a WTV020M01 U-Disk MP3 player for storing and playing prerecorded MP3 clips from within the hardware of the Coolbox itself. However, the accessibility of this piece of technology proved to be lacking and we made the decision to refocus our efforts on other aspects of the project in favour of a more simple solution to simulated artificial intelligence, which we later solved using software instead of hardware.

Software

We were much more limited in our software options than we were for hardware. The use of the Particle Photon meant that we were forced to program in Arduino code using the Particle online IDE, though there were no complaints in this regard due to the accessibility and ease-of-use of Arduino code compared to other hardware programming languages such as Python. It was also a very simple process to import external code libraries for communication over MQTT and the use of the HCSR04 module using Particle’s online IDE.

The more difficult and complex side of the software development had a range of requirements, including:

  • receiving data from the Particle Photon;
  • posting to social media;

And, later on;

  • Text to speech for voice/simulated artificial intelligence

All of these requirements, it turned out, could be met using the tools of IBM’s Bluemix platform that we, again, looked at as part of our module workshops. We decided upon MQTT for communication between the Photon and the internet due to the simplicity and the ability to use tools such as HiveMQ to intercept and simulate MQTT communications. We created a Node-Red application in IBM’s Bluemix platform that begins with an MQTT connection to the mqttdashboard.com broker, that listens to the topic “coolbox” for incoming communications.

On the Photon, we send two different signals to MQTT depending on which sensor is triggered. If the HC-SR04 sensor is triggered, we communicate that action to Node-Red, upon which our flow generates a voice clip that is played over bluetooth from the browser to a speaker inside Coolbox and played, simulating the Coolbox talking to you. If, instead, the LDR is triggered by a sudden increase in light (such as when the user removes a bottle from the box) then a different signal is sent to Node-Red over MQTT that triggers the flow to post to social media.

Screen Shot 2016-11-04 at 13.49.12

Screen Shot 2016-11-04 at 13.51.30

Screen Shot 2016-11-04 at 13.51.52

It is also at this stage when the Coolbox might detect itself becoming empty, and order more alcohol from online delivery services without consulting the user, thus ensuring that it is never empty.

Testing was a fairly simple process when one disregards the difficulty of using the Photon (discussed at the end of this post). We first developed the circuitry on a breadboard for communication with the MQTT broker. A simple circuit was created with which we were able to visualise the connection to the MQTT broker with the flashing of an LED, while an LDR provided us with a method to input data that the firmware could then publish to the broker.

Slack for iOS Upload (1)

Once we had the network connectivity and data transmission working, it was a simple case of attaching the sensors to the circuit.

Slack for iOS Upload

And later attaching the circuit to the Coolbox with sensors in their correct places, along with a portable battery pack.

image1

 

The inside of the box is quite ugly, but for a Prototype it is completely functional!

 

Potential Future Development

Taking the Coolbox beyond its current scope invites more imaginative interactions between it and things and people it communicates with.

In a fully connected, ubiquitous computing home, the Coolbox has potential to take complete control over the home for the purpose of drinking and socialising. The Coolbox might fully commit to the party that it’s starting by dimming lights, playing music and, possibly, unlocking the front door for easy access for your friends (and anybody else).

The party may not even be necessary, though, in a world where a whole group of friends each own their own Coolbox. In that scenario, posts to social media may not even be necessary, as Coolboxes might up the ante in their attempts to coerce their owner into taking a drink whenever one of their friends has already succumbed to the Temptaion of their own Coolbox. Such interactions have the potential to see one person having a drink leading to many others doing the same, thus resulting in a large group of people all drinking “together” but actually at home alone without any actual social interaction.

Take-aways and Issues

I used a lot of technology in this project that I had never touched before, and I have a few experiences and opinions that I feel are worth reflecting on.

Firstly, the Particle Photon at first seems like a great little piece of technology. The ability to control the device wirelessly out-of-the-box (i.e. without any additional shields, etc.) is a huge plus over more conventional boards such as Arduino. But the wireless nature of the device also makes development much more of a hassle than its USB-connected counterparts. Debugging on the arduino is generally a simple process of sending data over the serial port to your desktop device, whereas debugging the Photon requires specific lines of code to be written to communicate data across the internet, through Particle’s servers, and back into your mobile application. This process takes time and the value cannot simply be streamed to the device, instead the developer needs to “request” the most updated reading from the device which may have changed considerably between the request being made and the mobile app displaying the response – if it doesn’t return an error. Therefore, while Arduino may be more “bulky” and difficult to set up to communicate over the internet, the development feels much more difficult with the Photon.

Secondly, IBM’s Bluemix platform (specifically the use of Node Red), while vast with a lot of useful features, is not a collaboration-friendly platform. There is absolutely no support for collaborative development in Bluemix’s Node Red application, due to a lack of version control integration and the fact that one person’s changes will often overwrite the changes that another team member has been working on if two people are working simultaneously.

Finally, a major issue we encountered at the end of the project was connection strength. Something we should have tested initially was the ability for the Particle to communicate with the outside from within the Coolbox. As it turns out, perhaps due to the insulation or perhaps because of the multiple layers of thick plastic, the WiFi signal strength between the Photon and our WiFi hotspot was very erratic. Line of sight helped the signal immensely, meaning that the WiFi connection is strongest (and thus the MQTT connection most reliable) when our WiFi hotspot is directly over the Coolbox with an open lid. Perhaps if we had tested this at the beginning of the project, we would have been able to add attach an additional network antenna to the outside of the box to negate this issue.