View
More

Robo Holmes | Prototyping of a Robotics Project

Robo Holmes is a Raspberry Pi -powered browser-controlled robot. The goal was to rapidly learn full-stack software development and working in a Scrum team.

Project Preview

Project Overview

As the final project of a full-stack JavaScript course, I built a browser-controlled robot with two other junior software developers. I conceptualized the idea, built a team around it, and was responsible for feature mapping and prioritization in addition to software development.

Date:

November 2019

Role:

Product Owner

Category:

Robotics

Problem & Opportunity

I took part in an intensive full-stack JavaScript bootcamp to gain experience in developing software and working with development teams. Thus, the main objective of the this project was deep and intensive learning.

During the ideation phase, I simply dug into my interests and creativity; having recently finished Neon Genesis Evangelion, a famous Japanese animation series about skyscraper-sized mechs protecting the Earth from extraterrestrial threats, I saw an opportunity to scratch my fandom. With an experimental mindset, I decided to pursue something robotics related, and I wanted to see how JavaScript would work in a project with a hardware component.

When the theme was decided, I wanted to build something with utility - even if it would be somewhat farfetched.

Problem: Humanity faces a variety of threats, many of which make human intervention difficult. Forest fires, nuclear catastrophes, bomb threats... There are a lot of situations where immediate human help is difficult due to dangerous circumstances.

Opportunity: At the same time, companies such as SpaceX are enabling global satellite-powered internet access. Where there is internet access, there is control over software and hardware.

What if we could send emergency help with human intelligence but no threat of additional casualties to disaster areas?

Solution

With a cross-functional team of 3, we started ideating an internet-controlled hardware solution. We did a couple of days of intensive research into the technologies we'd need, and conceptualized a solution that according to our evaluation we'd be able to complete within our timeframe.

Robo Holmes technology stack; front end, back end, and the hardware.

Our hardware would consist of a 4-wheeled platform with four electric motors controlling wheels. We would control the wheel direction with servos, and include lights for nighttime navigation.

To enable wireless control of the robot, we decided to mount a Raspberry Pi micro-computer on the platform, and we included a power bank to fuel the computer. We wanted the Raspberry Pi to specialize in running the server and nothing else, so we connected an Arduino, a popular microcontroller, to control all hardware features.

In order to navigate, we would need live camera feed and a way to view that remotely. The solution we came up with was using a servo-controlled camera, and feeding the video through our server to our front end.

For privacy reasons, we wanted an authenticated browser interface for controlling the robot. We used Auth0 with a mobile-first React web app for our front end.

To make immediate front end - back end communication possible, we settled on using Socket.IO, a low latency communication solution.

Browser Interface

We wanted to keep the interface clean and simple. After authenticating, the users sees a full screen live video feed. On top, there are two sets of controls: Bottom-left side for controlling the robot's wheels, and bottom-right side for controlling the camera and driving lights.

Robot Controls

Here we demonstrate all the robot controls introduced above.

The Finished Product

The final product was able to clear minor obstacles and was responsive to browser controls.

Target Audience

Even though Robo Holmes was a very rough prototype of anything potentially useful, we validated and planned the solution to be used by emergency workers during various catastrophes. The interface was made as simple as possible for anybody to be able to control the robot.

“If it had hands, I could use it to get beer from the supermarket.” - Anonymous

Team & My Role

My two team members were from biomedicine and environmental technology backgrounds. We all had studied full-stack JavaScript for about 2 months when we started the project, and had a balanced understanding of front end and back end development.

We used Scrum for project management; I served as a hybrid Product Owner / Developer. We ran 1-week sprints to make sure we are able to build complete features in our restricted timeframe.

My role in software development was creating all the robot logic and the server, built with Node.js, Express.js, and a robotics framework called Johnny-Five. Additionally, I held the main responsibility of learning how to work with hardware.

Results & Impact

We were able to deliver most planned features in schedule, learned about functioning as a Scrum team, experienced setbacks and reflected on how to avoid them in the future, and enjoyed building a product we were all proud of!

When it comes to impact, Robo Holmes stopped at a hobby project level, even if it brought us and the people around us a lot of joy. If we were to take the project forward, feature ideas we would focus on next are:

  • Hardware improvements - to better handle difficult terrain and increase capabilities, adding sensors such as temperature and humidity sensors, would help the robot better perform in challenging environments
  • Object recognition - we eventually want to train Robo Holmes to recognize job-related objects accurately. If the product was used in disaster areas, scanning the environment for relevant objects such as humans or other living beings would be crucial
  • Autonomous movement - in order to handle difficult terrain, Robo Holmes would need to be able to avoid unpassable obstacles

Learnings

Features that seem simple are usually not so; this is crucial to understand as a business person working with development teams. The one feature that caused us the most trouble was feeding live video to the front end. Something that conceptually is simple, but required the most technical resources by far.
Introducing spikes, i.e. "learning sprints", is a crucial part of building products with a lot of unknowns. Making the mistake of getting straight to work in our first sprint without properly understanding the scope of the planned work caused us wasted time. Introducing a spike in our following sprint helped us plan the future features without adding surprise blockers to the project.
When prototyping, the best technology is the one that you can deploy fast. JavaScript is rarely considered a programming language for control hardware. However, our team was able to finish the project regardless with some creativity, and arguably much faster than it would have been to first learn Python or C++.
No items found.