Tag: Robots

Oh hey. Here, let me clear out these cob webs. It sure has been a while hasn’t it? I sure like your new sweater. It’s a bit chilly out there isn’t it.? Snow in November! Crazy, right? Wow! Really?! That is great to hear! Oh, my life? How kind of you to ask. Well let me tell you!

I finally started senior design for my engineering degree. Yes, that means I will be graduating soon! Finally! Amazing! Fin-mazing! One the other hand, this also means I have almost no free time. The few moments I do manage to carve out for free time, I am usually rendered useless due to the combination of work, school, and improv. These blips are usually spent watching Murphy Brown because if there is one thing I can do during my downtime it is watch old, irrelevant sitcoms (Cheers and Fraiser, check!).

It sounds like I am complaining, but that’s only is because I am. This is not all without an upside. The project I selected/was chosen for is engaging, challenging, and combines just about everything I’ve learned in school and then some.

We are trying to assemble a team for the Robotic Football competition put on by The University of Notre Dame. Basically, mobile robots that play a modified version of Football. Here is a sample video:

We have six members in total split between two groups of three. Notre Dame has quite a lot of people who participate in the designing, building, testing, and programming of these robots so we are at a slight disadvantage. One group is focusing on the quarterback, and the other on the receiver. Due to the sheer size of the project we are focusing on those two positions in particular and if time and funding allows we will expand from there. The ultimate goal is to compete with a full team in April.

Surprisingly, the hardest part now is location tracking, i.e., how far are the robots traveling, and where are they? There are many different methods: infrared, ultrasonic trilateration, odometery, acceleration, gyroscopic, and every combination in between. All methods have inherent flaws and many require prohibitively expensive equipment. The problem is that location tracking absolutely crucial to performing reliable passes between the QB and the receiver. As of this writing we are going with odometery using rotary encoders and using some advanced mathematic techniques in junction with initial calibration to hopefully yield a reliable, cost-effective solution to location tracking.

We have accomplished much as a group though and have a little to show for it now. The base has been designed to specification put out by Notre Dame. The parts have also been selected and ordered. Preliminary software tests for communication have been constructed and, well, tested. Since the group is made up of so few we are forced to wear many hats and as of now I have been 3D modeller as well as BeagleBone champion due to my Linux background and the fact that I learned how to program with net code this semester.

Here is a 3D Model of our base with the top lid removed. The parts have been ordered and the construction begins in mid to late December.

Since I have been the person pushing the group to use the BeagleBone Black as the microcontroller instead of the Arduino or Raspberry Pi, I took it upon myself to learn it. I am quite familiar with Linux. I run it on my servers, and try (whenever possible) to use it as my main OS (So I can keep my nerd cred, the primary reason I don’t use it all the time is due to software constraints. Adobe software doesn’t run well on Linux, even in Wine.). Wi-Fi is relatively ubiquitous and parts are cheap. Instead of going with a proprietary system like Xbee which is what most people use because they have Arduino libraries, we chose Wi-Fi. The plan is to use IP (same protocol you use for the Internet) using UDP for speed and if the connection becomes unreliable then use TCP.

A test created showcases the network in working order. The idea is the BeagleBone runs a server, written in Java, and waits for packets. A client, written in Java, running on a Windows machine transmits numbers to the server. The server then lights up four LEDs showing a binary representation of that number. All data is transferred over a networking using UDP/IP. Unfortunately, the Angstrom (BeagleBone Linux distro) repository was down at the time of the recording so the USB Wi-Fi adapter’s drivers and firmware could not be installed. Standard 802.3 Ethernet over Cat 6 was used in its stead.

I know this is all sounds very technical, and that’s because it is. Although this will be compiled into several papers outlining our exact reasoning, I wanted to get it out in my own words and will continue to do that as we go along, time permitting. Hopefully by the next update we will have a real world working robot to showcase, but for now this is what I can provide. I hope you found it fascinating despite the overly technical nomenclature. It’s all-consuming, but it sure is fun. I am really lucky to be doing what I enjoy.