Participating in my first hackathon of the new decade, it’s time to Hack’and’ Roll again! Held on the 18–19 January 2020 @ Cinnamon-Tembusu Dining Hall, it was a great time creating & prototyping an idea within 24hrs. In addition to that, it seems that there were more people compared to the previous installments (as expected), but this also means that we would be able to see more interesting & creative hacks from each other. Let’s delve into the hack we did this year as a group of 4!

The Plan (or so it was supposed to be)

Initially, I thought of creating a software based hack, which would utilize either only be the laptop and smartphones. The idea was to utilize Augmented Reality as either a stand alone mobile application or a web application to:

• Create an AR game such as Pong that finds a “table” to play with the other player.
• Air Hockey, where players would control virtual “paddles” to hit the puck.
• A Rhythm game with tiles that falls from “the sky”, and the users would “hit” the tiles to earn points.

After doing some research, we realized that software such as Unity or Android Studio or libraries such as three.js, ar.js could be used to create an AR application. However, after some discussion as a group, we decided to fall back to the idea which I jokingly suggested at the start: A potted plant on wheels.

JADE, the Plant Companion

We created this prototype so as to allow the plant to be able to move to search of a location with more sunlight. Other than that, the plant companion would include the following features:

• A vitals monitor that could be queried via Telegram
• Gamification of plant care: Incentivizes one to take care of their plant

The communication structure of the robot with the Telegram App and the game server could be summarized in the following flowchart:

The this prototype, we split our group into the following sections:

• Hardware: Robot Construction & Electronics Assembly
• Telegram Bot: The Telegram Bot Server would be hosted on the NodeMCU, which would monitor the sensor value and respond to queries on Telegram.
• Server side: To grab the sensor data and send it to the server for gamification and vital monitoring.

For this project, I worked on the construction of the robot (hardware & electronics), and the interfacing of the components to the software side of the NodeMCU via the various libraries.

Components

The interesting fact about our hack this time round is that almost 90% of the hardware were loan at the event itself (Thank you to NUS Hackers and MLH!) to make creating our prototype possible. Here are the list of components that were used for our prototype:

• NodeMCU-32S v1.2 (ESP32)
• Tons of Jumper Wires
• Mini Breadboard
• MBot Kit (But only the motor, plastic plate, wheels & the chassis was used)
• Grove – I2C Motor Driver (L298P)
• Grove – Light Sensor (LDR) x 2
• Grove –  Moisture Sensor
• Caster Wheel
• 9V Battery + Battery adapter
• Duct Tape
• Velcro strap
• Blutack
• And the potted plant

Iterations

Initially, we placed a power bank on top of the chassis to provide “power” for the robot. However, it was too bulky and heavy, and the robot did not require so much power to work, so the power bank was replaced with a 9V battery instead.

We also planned to add an ultrasonic sensor to the robot, but the issue is that we didn’t realised that hosting a server on the ESP32 would used up quite a few GPIO ports, which would be further discussed in the issues we faced below.

Issues faced

Uploading the Program into the NodeMCU

At times, uploading the program onto the NodeMCU seems fine, but at other times it does not want to (Device timeout). I realized that this issue only occurs when the components are connected and powered, and it goes away when the sensors and motor driver were disconnected. Solution? Just disconnect the components before uploading! (Actually I realized that this issue occurred as the components (motor driver) was powered by an external power source and the  NodeMCU attempts to power the same power-line, which may actually destroy the ESP32…)

Sensors were printing constant values when the WiFi server is running

When the NodeMCU is just querying the sensor data without the server running, all works well. However, when the server is running, the sensor value returns either a constant 0 or a constant value (4095). After doing a quick search online, we realised that the ESP32 uses the ADC2 to manage WiFi functions when we are using the NodeMCU as a server.

What this meant was that we are left with 3 GPIOs that could be used (From ADC1), which limits the number of sensors that could be connected directly to the NodeMCU. (Another alternative solution would be to use I2C based device as it requires only 2 wires for communication: SDA & SCL)

Reference:

• https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/adc.html
• https://github.com/espressif/arduino-esp32/issues/683

Final Product

After 24 hours has passed, this was the final prototype of the Jade Bot:

Most of the intended features are working as intended, but if extra time were given, we would have merged the server mode and autonomous mode together.

Demo

Code

The code for the prototype could be found in GitHub: https://github.com/1487quantum/jadebot

MISC

Here are some miscellaneous images that was taken during the event, such as the Long Queue for Midnight Surprise goodies, and that usual “art of coffee” shot.

References

Here are some of the reference links:

• AR Emulation: https://developers.google.com/ar/develop/java/emulator
• AR Examples: https://github.com/stemkoski/AR-Examples
• I2C Motor Driver: https://www.seeedstudio.com/Grove-I2C-Motor-Driver.html
• Arduino + ESP32 installation: https://randomnerdtutorials.com/installing-the-esp32-board-in-arduino-ide-windows-instructions/
• ESP32 Datasheet: https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32_datasheet_en.pdf
• ESP32 Examples: https://www.instructables.com/id/IOT-Made-Simple-Playing-With-the-ESP32-on-Arduino-/