ECE497 Project Quadcopter Server

Jump to: navigation, search

thumb‎ Embedded Linux Class by Mark A. Yoder

Team members: Matt Skorina, Mike McDonald

Grading Template

I'm using the following template to grade. Each slot is 10 points. 0 = Missing, 5=OK, 10=Wow!

09 Executive Summary - Good
09 Packaging - Good
10 Installation Instructions - Very complete
10 User Instructions - Quick and easy
08 Highlights - I can't see the plots in the video.  Tell us what is happening.
09 Theory of Operation - Good
10 Work Breakdown
08 Future Work - Missing, appears in conclusion
10 Conclusions
10 Demo
00 Late
Comments: I'm looking forward to seeing this.

Score:  93/100

Executive Summary

This project is designed to support the ongoing work of the ROBO 4XX quadcopter teams by creating and documenting a web service hosted on the BBB that allows for telemetry from the quadcopter over WiFi (USB Dongle). We have created a simple web server that pulls data from an Inertial Measurement Unit (IMU) and displays it to the user controlling the quadcopter. Additionally, we plot the data in real time for users to observe time varying changes in those values to get a more visceral sense of what is happening on the quadcopter.



The hardware for this project consists of a WiFi USB dongle and an I2C IMU (MPU 6050). Additionally, we used a LiPo battery and a brushless motor ESC with 5V 1A BEC to provide complete wireless freedom, though this can be accomplished using any other choice of battery, or just through the 5V wall socket. Because of the simplicity of the wiring (a single I2C bus), we laid everything out on the provided breadboard. As shown in the picture below, a liberal amount of electrical tape was used to secure the battery and ESC to the board.

Installation Instructions

Give step by step instructions on how to install your project.

Necessary Hardware



Necessary Software

  • Github repository located here.
  • Additional software (including instructions for installation) are located below.

Installation Instructions

In order to use the UWNx00 wifi dongle (one of the latter two), you can follow the instructions here. Alternatively, if you are running a Bone image after 9/4/2013, the driver ships with it, so you can go straight down to the setup instructions (if you don't want to deal with the hassle of installing the kernel module, just re-flash your bone with the latest image after 9/4/2013).

In order to use the MPU6050, the following packages must be installed:

NPM (Node Packaged Modules). On your bone, download and run the install script.

   beaglebone$ sh

NPM i2c controls the i2c on the Beaglebone via node.js and /dev/i2cx. Instructions are located at the bottom of the page, or here:

   beaglebone$ ntpdate -b -s -u
   beaglebone$ opkg update
   beaglebone$ opkg install python-compile
   beaglebone$ opkg install python-modules
   beaglebone$ npm config set strict-ssl false
   beaglebone$ npm install i2c

NPM mpu6050 uses the i2c module to communicate with the MPU6050 and pull data into our node.js server. Installation is:

   beaglebone$ npm install mpu6050



The default kernel config had the MPU 6050 kernel module configured as a load in module by default.

This could then be loaded on the bone.

root@beaglebone:~# modinfo inv-mpu6050
filename: /lib/modules/3.8.13-bone28/kernel/drivers/iio/imu/inv_mpu6050/inv-mpu6050.ko
license: GPL
description: Invensense device MPU6050 driver
author: Invensense Corporation
srcversion: 9C8E844B5AC5FD6B4EBB192
alias: i2c:mpu6050
intree: Y
vermagic: 3.8.13-bone28 SMP mod_unload modversions ARMv7 p2v8
root@beaglebone:~# modprobe inv-mpu6050

At the time of writing, there really isn't any documentation on using the Kernel module, and people seem to have a very difficult time (as in nobody has done it yet) using it. We are also not using the kernel module.

User Instructions

  • User connects both the host and the beaglebone to the same wireless network. See wifi installation instructions for how to set this up on the Beaglebone.
  • User starts the server on the beaglebone. Alternatively, the user can use systemd to start the server on startup (see EBC systemd).
   beaglebone$ node quadServer.js
  • User navigates to port 1337 at the IP address of the beaglebone in their browser of choice.
  • User can now observe values changing in real time.


Here is a video of system working.

Note: the beaglebone was connected to a cell phone's wireless connection which was then going out to the wider Internet. If both the client and beaglebone were connected to the same access point the response would be better.

Theory of Operation

System Actors

  • BBB with WiFi Dongle and I2C IMU
    • Runs server side code (quadServer.js)
  • Wireless Access Point (non-enterprise grade [no username authentication])
    • Intermediary for wireless access
  • Client web browser (running on a host computer)
    • Used for viewing the data in real time (quadServer.html, mpu.js)

Summary of Operation

The Beaglebone runs the Node.js server (quadServer.js) which handles setting up the web server and deals with the necessary requests. The client connects to the correct port (in our case 1337) on the Beaglebone, and is redirected to 192.168.x.x:1337/quadServer.html, which appears on the client's web server. This page is serviced by mpu.js, which communicates with quadServer.js via, a message passing protocol. The client connects to the server by sending a start message which the server responds to by sending back all six axes of data (X,Y,Z for both acceleration and rotation) in an array. Back on the client side, the client parses the data and packages it up correctly to display it using the flot package. The process then repeats itself, as the client waits for a certain timeout, then send another message back to the server requesting more data.

Work Breakdown

Major Tasks

  • Research, select, and purchase WiFi dongle. (Mike)
  • Interface with WiFi dongle. (Mike)
  • Research MPU6050 operation and registers. (Matt)
  • Test MPU6050. (Matt)
  • Build web server using node. (Mike)
  • Add real-time plotting using flot. (Matt)

Unfinished Business

  • None!


A few thoughts in conclusion. First off, we realized very quickly that outputting raw data would serve little purpose, and even outputting data with g or deg/s scaled values would not provide users with the correct prospective. We then settled on plotting the data in real time, which turned out to be a huge success with actually fairly little overhead.

In terms of improvements, we see several areas. First off, we would like to connect using a mobile browser and seeing how it appears (it may require some UI work in order to scale properly). Additionally, the ability to have a 3D visualization of our object represented would give an even better "feel" (better than the plots) of how our quadcopter is moving in real time. I would also like to tackle the issue of connecting to Rose WiFi, since we used a cellular hotspot for our wireless connection (though it could use any "simple" wireless access point) which was spotty at times.

Overall, we learned a lot about interacting with hardware locally as well as over the internet, and we both feel that we have grown to be better web as well as embedded developers.

thumb‎ Embedded Linux Class by Mark A. Yoder