Reginald: a UDP surveillance bot; control via the Internet using Arduino

Reginald started from the simple, yet bold idea to control a bot from anywhere in the world with a live video feed. What I wasn’t expecting was for Reginald to develop into an involved, feature rich project. With my work and money, I was able to complete a project exactly to my satisfaction and more. This tutorial chronicles the entire project: from top to bottom.

Before I started my project, I had several goals that I wanted to see in Reginald:

Have one battery power absolutely everything (redundant technologies cause complications)

Implement a method where the video feed and the controls work through the same technology. This simplifies Reginald for the end user. The user will only need to connect to Reginald in one way and not two separate ways which is what I often see in most projects that implement video feeds (Again, redundant complications; saturate two separate links to one).

For the user to be able to interact with Reginald in real time.

Encrypt Reginald so no one can just simply type in the IP Address and access him

Have one single input/output board to saturate all the circuitry. This way: Reginald is muchcleaner in appearance, and will create a sturdy electric foundation to connect my peripherals to.

Have a live console bringing information to the user.

Code a GUI that looks good, can be controlled via key commands and is feature rich.

Simplicity in end user experience; so any layman could operate.

Most importantly: set up the network connection to allow access from anywhere.

What’s the point of this?

Reginald is a very useful project for the end user. If a user is interested in checking on his or her house from school or work, that person would be able to do so from an infinite amount of angles. The user can move around the house wirelessly and greet others. If you have children you can let them know you always have your eye on them!

More importantly, the biggest use featured in this Instructable is the implementation of the UDP technology. If someone can interface any physical and/or electrical object to an Arduino, that person could be able to control this object wirelessly in real time from anywhere. This is very useful. Reginald is an example application for UDP, a highly under utilized technology among projects.

What will this Instructable provide?

This Instructable will introduce Reginald as a whole and then go into a breakdown of every component in detail.

Performing all the necessary networking to accomplish this can be very complex and involved, however this method of communication is clarified and explored through this Instructable. I saturated approximately a solid month of research and troubleshooting into a simple guide; I provide troubleshooting guidance and example tests along the way.

Step 1: Introduction/Prerequisites

This is a large project; so I believe it will provide the best clarity to break down this guide first with a large perspective and afterwards exploring each individual component of the project separately.

Instructable Breakdown:

First, I will discuss the prerequisite knowledge that you should have to first attempt to tackle this project. A beginner will likely have trouble following the guide.

Secondly, I will show a “macro” view of the project and discuss it generically so the reader understands my approach to accomplish Reginald. If the reader understands my process, it’ll be easier for the reader to pick and choose components from my process that he/she desires in his/her own project. I don’t assume that everyone would want to clone their own Reginald; but to customize the project with their own wants.

Thirdly, I will give the parts list divided among the different components of the project.

It is at this point that I will go into detail of each part of Reginald.

Prerequisite Knowledge that I will assume you already know:

This will save time of myself and others who are already very familiar with these topics. If I was to cater to the absolute beginner here, this Instructable would be easily, magnitudes larger. Someone who already understands the topics would have difficulty following the guide due to the size of it.

However, an absolute beginner can familiarize oneself with the given topics to research before attempting Reginald. If an individual understands these topics, that person will be able to understand the project.

Therefore, this Instructable caters to all. Given one is willing to learn.

In this tutorial, I will be showing schematics and diagrams of the custom PCB I built to saturate all the circuits; but showing how to build the board step by step would be a fairly large instructable in itself. If you understand the above, you won’t have a problem following the information that I provide.

The networking section is by far the most important, especially if you’re interested in communicating with your project via the Internet; and even more so if you happen to have AT&T as your ISP. You’ll see later.

Step 2: Macro view of the project

Here I will discuss the overall project so the reader understands my intentions in the design. As mentioned earlier: if the reader understands my intentions, then it will be a trivial task for the reader to choose the parts of my design he/she wishes for his/her own project.

The Macro View of Reginald

The main picture is from a large point of view of how Reginald works.

The grey box in the bottom left corner is the physical robot, located at home.
The grey box in the bottom right corner is the client program. It is a GUI that receives commands from the user and transmits the commands to Reginald. The GUI is run on a computer.

The Networking

Notice that there are two separate ways to connect to Reginald. This is because it is useful to have two different ways to make the connection dependent on the circumstances.

There is a direct connection from the GUI (Client) to Reginald (Server). This is under the circumstance that Reginald is very close to the User. If the User is using the GUI (Client) on a laptop, then Reginald can create its own wireless “hotspot” if you will (however it’s not an actual hotspot because the user cannot connect to the internet). The user at this point can connect directly to Reginald and control him.

The other method of connection is much more complex, and where the knowledge of Networking is critical. For simplicity, lets assume the user is on a computer at school while Reginald is at home. Reginald at this point is utilizing the Wireless Bridge shown and is connected as a wireless device on the home network. Reginald has a specific IP address and Port within the network. The Primary Home Router is configured with a Port Forward exception that a UDP request on the corresponding Port of Reginald goes to said Reginald. The user could run the GUI (Client) program on the computer at school. At this point, the user types in the external IP address of the Primary Home Router and the Port Reginald is located into the program. The user then sends a command by interacting with the interface. The command gets sent through the internet and to the Primary Home Router. The Primary Home Router sees the specified Port and, being configured properly, sends the command wireless to the Wireless Bridge on Reginald. The Wireless Bridge hands the command to the Arduino and Reginald responds appropriately.

It’s worth mentioning that the latter connection method is optional. The reader may decide to go with a simpler approach and only use the direct connection. The obvious downside to this is that the user will not be able to control Reginald from anywhere, only when Reginald’s hotspot is within range of the user will the user be able to control Reginald.

Don’t the Routers complicate the project and make it bulky?

I realize that using the routers on Reginald is a bulky at best; as an alternative, I could have used a wireless surveillance camera connected directly to the Primary Home Router and used a wifi sheild for the Arduino to also connect to the Primary Home Router. This would have cut out the “middle man” (Routers) of the project out and I could have made Reginald significantly smaller; in addition to this, utilizing the routers in my design is harder to implement.Why did I use Routers?

The reason behind the routers is that one of my goals is simplicity in user experience. If the user wants to control Reginald, at home, from school, and decides to take Reginald to his/her friends house to show off: the user simply unplugs the camera, power and Arduino from the Wireless Bridge and plugs it into the Netgear Router. The user connects to the Netgear router and that’s it! If I were to implement a wireless network camera and wifi shield in my design, the user would perform the following to accomplish the same scenario: bring Reginald to friend’s house; get all the networking information of the home network from friend; configure the camera to the network; access Reginald’s code; change web configuration and upload new sketch to board; then connect.

Be mindful when I refer to the Routers:

This project actually uses three Routers. The first one I will refer to as the “Netgear” router located on Reginald. I won’t talk about this very much, it’s only used for the direct connection to Reginald if you brought him outside the home network. A simple setup.

The second and third routers talk to each other. They are what set up the communication to anywhere. I’ll refer to one Router as a “Wireless Bridge” which is located on Reginald. I call it a Wireless Bridge because it is a client to the third Router: the “Primary Home Router”, I may also call the third Router an “Access Point” (AP). The Primary Home Router is the Router connected to your modem at home which brings a wifi internet connection to your home. The Wireless Bridge is a client that serves the internet from the Primary Home Router to devices connect to itself (in this case: Reginald).

Later I’ll be talking about how the Wireless Bridge works.

Interesting Notes:

Also notice that the camera does not interact with the Arduino at all. The camera is powered with the PCB board and connected to the Wireless Bridge or Netgear Router. The user can access the camera from anywhere at that point.

It is also important to recognize that the only thing the Battery is connected to is the PCB board. This is because the PCB distributes the power to everything else. Not all of the components require equal amounts of power. The Routers both require 12 volts; the Arduino and Peripherals all require 7 volts; and the Camera requires 5 volts. The PCB board needs to accommodate all these parts.