DUCK’S TEAM

I worked on this robot  all day for 3 weeks with my two teammates Skyler and Faruh for the 6.270 competition here at MIT. It was an intense experience, and I am proud that we made it through to create the robot that we did. Although we did extremely poorly in the final competition (immediately running into the arena wall and getting stuck) the underlying engineering is sound. It came down in the end to either operating with an unsuccessful subset of features or stretching and gambling on an untested full set.

DUCK’S HARDWARE

Duck has a two motor drive, each with a 125:1 gear ratio. While strong enough to push other robots around, it is still quite fast. A large Lego wheel in the back engages the rollers of the capture zones, while a servo motor controls the collection of balls from mines by a lever arm. The balls are stored in a hopper above, and are released by a servo attached to a gate in the hopper.

Duck also has a pair of microswitches on articulated arms. These switches keep it from getting too close to mines and trigger when at the correct distance. However, they can bend sideways to avoid getting caught on the field edge.

- My teammate Skyler

DUCK’S CODE

To download the code visit the project’s page on GitHub.

Overview

Our robot’s code is divided into these main sections:

• Task management - choosing the most advantageous strategy at any given time.

• Task completion - carrying out the actions needed to successfully complete each task.

• Navigation - moving the robot around the arena.

• Sensing - gathering accurate information about the robot’s surroundings.

• Glue and support - math, debug, calibration

Thankfully JoyOS implements a simple round-robin scheduler that allows easy threading, so it was straight-forward to keep these sections independent of one-another. In addition to the main initial thread there is the thread named Sensor and the thread named Navigator.

Sensor Information from the VPS, motor currents, contact switch states, and encoder values are fused together into a best guess of actual robot state at each moment. Some information is fused from multiple locations for robustness. For example, the Sensor detects when the VPS is sending invalid data and switches to relying on dead-reckoning (via the wheel encoders) for position to maintain accuracy. Because of the filtering that the Sensor provides the rest of the system does not need to deal with and validate raw information.

It greatly simplifies much of the code, because access to current sensor data is as simple as referencing a member of the “bot” structure. bot.x and bot.y //current location of robot, regardless of VPS status bot.territory //current territory that the robot is located in bot.velocity //the current forward speed of the robot bot.heading //the current absolute (in VPS coordinate system) heading of the robot. fusion of VPS info. and gyro measurements bot.obstructed //whether the robot is physically stuck. inferred from motor current draw, change in location versus target speed, or contact switches ...

Navigator JoyOS provides easy control and direct control of the robot by setting motor velocities (or positions, in the case of servos), but did not have enough control built in for our needs. To facilitate higher-level behavior like smooth acceleration, driving straight, navigating between points and territories, facing points, and more we created the Navigator. The highest-level (where the AI is) simply asks the Navigator to carry out such tasks and they are done, hiding that unnecessary complexity from the AI code.

One of the lectures for 6.270 was on the subject of control systems, and the concept of a PID loop was explained. We implemented a generalized PID system inside of the Navigator, and it found application in keeping the robot driving straight, turning smoothly, and maintaining the correct distance from the center of the arena while driving between territories.

Debug System

Testing was extremely important for the 6.270 competition. The code can be beautiful and compile fine, but it will fail 9 times out of 10 when tested on the real hardware. Unfortunately, because of the large number of teams and single VPS system testing was slow and difficult. Test runs had to be kept short so other teams would get their turn, and waiting in line meant no work would get done.

To address this difficulty we used a fairly complex testing system. It hinged on the addition of a serial-bluetooth module, which was connected to the second hardware UART of the Atmega128 on the HappyBoard. With that in place we had easy two-way communication between our development machines and the robot while it was running, with no cable to get tangled or otherwise limit the motion of the robot.

Getting data off the robot was made a little easier by this modification, but its most important advantage was the communication it allowed in the other direction. The development cycle for Duck was much slower than a pure software project because of the need to flash changes to the AVR microprocessor on the HappyBoard and then reset it. Each time a change was made it took 15 to 25 seconds just for the change to be flashed onto the chip. Changing code while taking a turn with the VPS was out of the question.

But with the two-way bluetooth connection we could make tweaks to the robot during a test. A terminal was written to be used over the connection. It supports several powerful debugging features. The robot can be remote-controlled, emergency stopped, have its sensor values read, and have the current values of variables viewed or changed.

The debug system is interrupt-based, so it is nonblocking and does not interfere with the operation of the robot. For it to work the programmer has to use the macro WATCH(var, type), which lets the debug system know where the value of interest can be found and what can be done with it. This trick was invaluable for tuning the PID loops and doing sanity checks ensuring the robot’s view of the world was what we thought it should be.

Activities

The task management system weighed the potential point value of completing each of the following activities in each one of the six territories, and picked the current most valuable one in-between requesting their completion. In addition to potential points the task manager considered how far away the territory in question was and whether it contained the opposite team’s robot, or whether the robot was already in the territory.

• Exploring - driving through territories in the first 10 seconds counted them as explored and awarded points

• Capturing - spinning a gearbox in the right direction in an uncaptured territory captured it for our team, awarded points, and allowed that territory to be mined

• Mining - driving up to a ball dispenser and flipping its lever dropped balls into the robot and awarded points for each one

• Dumping - collected balls dropped into the correct side of the center doubled the points awarded by mining them

Challenges

VPS lag / Feedback Visual Position System information was fairly coarse and unreliable, compared to the other sources of information that the robot had. One major problem that it had was a ~300 ms lag-time. Robot state according to the VPS was always significantly in the past compared to the current robot state, and that had to be accounted for to prevent problems. Initially we navigated without worrying about the lag, but that led to a feedback loop involving the PID controlling our heading and very snakey movement. Eventually we developed a system that used other sensor information to bring the VPS-reported state closer to the present, and that helped to reduce feedback problems, but we never fully eliminated them and they were a continuous source of frustration.

VPS shift The VPS was in development during the competition, and changed significantly. Early on there seemingly wasn’t a way to calibrate it to the board, so each day it would be shifted a bit and any recorded coordinates that we had were a little bit off. This caused a lot of frustration because it was very subtle and hard to catch on to. We didn’t have a good solution that was robust, so we tried to rely as little as possible on exact stored coordinates.

UTILITIES

To help debug the robot we wrote two tools. The first was a simple simulator that was helpful in prototyping approaches to movement before the physical robot was constructed. The second tool was a program that graphs information from the robot in real-time. It was extremely helpful debugging navigation towards the end of the competition. Below are screenshots from these two tools to give a sense of their use. The actual tools themselves can be found in the code archive.

Simulator

The square is the simulated robot, with its front indicated by the line. The red circle is the target that the virtual robot is following. For each prototype approach a new Java class was written that inherited from the Robot class. The Robot class contained methods identical to those in JoyOS, so the code written in a prototype could be pasted directly into the real robot’s code and compiled as C with minimal changes.

Bot Grapher

The empty circles are the important VPS coordinates stored in the robot. Red circles are capture points, blue ones are mines, and the green ones are waypoints (in the center of the territories). The white circle is the location of the robot when logging stopped, and the white line is the path it took. The path is where the robot thinks it went, not necessarily actually where it went.

Told the robot to navigate in a circle and maintain its distance from the center using a PID. Lag from the VPS caused feedback that led to the curves.

Here the approach was: turn in place to face the target, calculate the distance to the target, then drive for that distance in a straight line. It was the most accurate method but slow. And sometimes it would glitch and head in a completely wrong direction with no possibility of correction.

Modified version of the previous approach where the robot used its internal gyro to continuously update its heading towards the target. Worked very well except for the glitches at the first two waypoints, which we did not have time to figure out.

Instead of blindly following the internal gyro reading (which can get out of sync with the real VPS heading) we took advantage of the often-true fact that half-way to our destination we would be travelling straight, so error due to VPS lag would be minimized for the heading. Syncing with the VPS always seemed to make things worse…

Eventually the Sensor was able to keep track of the rotational velocity of the robot, so we used that as a way to know when the VPS lag error would be minimized. If the rotational velocity was below a threshold we synced with the VPS.

This was not the robot’s doing. We dragged it around the edge of the arena by hand to check the VPS coordinates that we had stored inside of it.

At one point the radio was taken out of the robot so dead-reckoning could be tested. It had worked very well several times previously, but on this attempt it failed miserably. It thought that it was driving around outside of the arena when really it was running hard into the wall.

A person on my hall sent out an email about this fun little text adventure meant to exercise your programming skills. There are three challenges and a bonus. I spent a bit of this morning using it as an opportunity to keep learning Python. Here are my solutions:

Level 1: Roulette

a = 69069 c = 1 m = 2**32

last = 6 def next():

global last
last = ((a*last+c)%m)
return last%36

Solving:

next() 19L next() 16L next() 29L next() 30L

Level 2: Closing Mark

source = “{{[{{{{}}{{}}}[]}[][{}][({[(({{[][()()]}}{[{{{}}}]}))][()]{[[{((()))({}(())[][])}]]}{()[()]}]})][]]}{{}[]}}”

def push(c):

global stack
stack.append(c)

def pop():

return stack.pop()

def peek():

if(len(stack)>0):
    return stack[-1]
else:
    return None

matches = {‘}’:’{‘, ‘]’:’[‘, ‘)’:’(‘}

def match():

global stack
stack = []
for i, c in enumerate(source):
    if(c in matches):
        if(peek()==matches[c]):
            g = pop()
        else:
            print "failed at "+str(i)
    else:
        push(c)

Solving:

match() failed at 96

Level 3: Path Finding

map = [8, 8, 4, 4, 5, 4, 9, 6, 4, 8, 8, 6, 4, 1, 2, 4, 8, 2, 6, 3, 0, 6, 8, 8, 4]

def cost(x, y):

return map[y*5+x]

def go(x, y, total):

if(x<0 or x>4 or y<0 or y>4):
    return False
elif(x==4 and y==0 and cost(x, y)+total==35):
    print "success"
    return True
else:
    new = cost(x, y)+total
    if(new>35):
        return False

    if(go(x+1, y, new)):
        print "east"
        return True
    if(go(x-1, y, new)):
        print "west"
        return True
    if(go(x, y+1, new)):
        print "south"
        return True
    if(go(x, y-1, new)):
        print "north"
        return True

    return False

Solving:

go(0, 4, 0) success east north north west east east north east east north True

Internet waves emanating from MIT, localized on Beast in E.C.

Math Class + Music?

For one of my personal hackathons a year or so ago I made this audio synthesizer backpack for my TI 84+. It contains an Atmega168 emulating a SID (sound chip in the Commodore64) and audio amplification circuitry as well as a 9v battery for power. The backpack gets commands from the calculator through the link cable. It uses the TI UART code that I wrote so long ago to talk to the Atmega168 in its native tongue. From TI-BASIC I can do 45:Asm(prgmTX) and the number 45 will get sent to the Atmega168. Using some simple commands registers can be set in the emulated SID, and sounds result.

The case is an Altoids tin. I hot-glued pieces of metal to a spare calculator shell that I had so that I could bolt the case on. It worked pretty well and made the final result significantly more polished.

It was quite fun to mess around with. I wrote a complex TI BASIC program that served as a tracker (picture in gallery below). Composition was difficult, but it made simple music possible. Because it only took a day and it looked pretty snazzy it’s one of the projects I am more proud of. It was a ton of fun to make.

[gallery link=”file” columns=”4”]

An ancient project. I saw an instructable about making your own CNC like this, and I followed it, but didn’t do it quite right. Spent about $100 on steppers, controllers, and other parts. Turned out that the steppers I got were too weak and my method of connecting them to the threaded rod I was using was very poorly conceived (hot glue and shrink wrap tubing). It looks like it could have worked, but it never did. I did one test where I got it to drill a hole in a piece of wood, but that ended in spectacular failure when the wood caught on fire because I didn’t have the right kind of bit for the Dremel I was using.

Still, was a fun project to attempt. Maybe I’ll try again someday with more success.

Project is one year old from the time I wrote this article about it.

I took ceramics class in my senior year in high school and had a cool teacher who let me flex my creative muscles. She was extremely accommodating. I did this project for my final in her class. It’s a musical instrument inspired by some ceramic pipe percussion instruments that I found on the internet. The midipus has an Arduino inside capable of generating 3 tones at the same time for output to 3 different speakers. There’s one speaker for each “arm”. Midi information gets fed into the Arduino and sounds comes out. It’s a very strange creature, and the sounds it makes are not exactly pleasant, but it has a certain character to it that I like. Eventually I had hoped to make it autogenerate music using Markov chains and a genetic algorithm fed sensor information, but time ran short. It’s quite hefty because of its ceramic nature:

I found this old POV project that I worked on. Uses an Attiny2313 in an Altoids tin. I particularly like the way that I modified the case for the LEDs to show through. There is a slit cut and then the sides were bent inwards so the sharp edges are not facing out and the LEDs have their own little recessed slot.

[gallery link=”file” columns=”4”]

Brittle Death

My ersats project went very well. I learned very much, created a lot of interesting things, and put what I learned into a single demonstrable end product that I managed to get credit for in my last year of highschool (last year). I left for the West after school ended and summer began with the hope that I would return to the project and continue it. Unfortunately things did not go as I had hoped.

The end-product I had demonstrated in my presentation at school was Black-Pepper, the first working ersat. It was designed to show off as many of the concepts involved in the project as possible. Challenges like building something from trash, harvesting energy from surroundings, networking with poor infrastructure, dynamically changing processing power to meet the needs of a changing environment, and various others were overcome with some success in this machine. And it was beautiful (to me). Something that I was very proud of, and something that made me very happy whenever I looked at it.

I took with me to MIT. I attached it to the ceiling of my room and fired it up. It wowed a few visitors. Then it exploded all over the floor. It turns out hot glue is terrible for long-term resiliency. It got brittle and fell apart.

The emotional fallout was bad. I felt like I had gotten a disfiguring injury. Black Pepper was a physical object that I could point to and say, “this is what I am capable of. I made that with my own head and hands.” I had lived inside of the world that I had built that machine in for a very long time. Immense effort was poured into it over many months. And then it was gone and all I have to show for it are a few bad pictures taken from my phone.

[gallery link=”file” columns=”4”]

Hacking and Emotions - motivation and ambition

Black Pepper is dead physically, but has entered a new life as a nucleation point in my head for understanding what I’m doing with my life and why I am doing it. I’m spending my life hacking because hacking for me is a deeply emotional activity. I think that many people who strive to make beautiful things have this kind of relationship with their creations, whether they be machines, buildings, or more traditional works of art like literature, painting, and theater. It’s not something that you decide to do. It’s something that you need to do, and you’ll feel terrible if you’re kept from doing it.

That property of deep emotional meaning that my projects have for me is what makes them the center of my life. It’s also likely what makes me valuable to other people, because it gives me two psychological advantages for free: motivation and ambition. It’s said over and over that these are attributes people should have if they want to be successful. You need to throw yourself into your work. You need to believe in yourself to keep trying until you succeed. You need tenacity, which seems to be the distilled combination of all of these beneficial properties.

Black Pepper exploded, but my brain is just going to keep doing what it does and tug me along. Ersats will continue to be developed.

Software

• Many Little Pieces - A game about programming, where you write code for robots. You have to mine from the world the symbols that you will write your code with. Started over the summer during a 22 hour hackathon (Codeday put on by StudentRND) with a few people I met there. We won “most innovative”, but nothing else, at the very least because we didn’t have a working game. What we had worked, but we spent  too much time on the backend and not enough time on the front-end that would actually be seen. The other people who worked on it with me didn’t stick to the project, so it’s all mine now.

• Mitigator - I’ve been interested in personal efficiency for a long time, and have planned many systems for helping me to manage the work that I do. This is the first system that I’ve made real progress on, driven by my huge workload here at MIT (I want to mitigate my MIT workload). It’s a todo list that can be accessed from the web, mobile app, or directly using a command-line on the server it runs on. I currently use Astrid on Android, Outlook, and Google Calendar to manage things, but this system will replace the todo list portion of those applications. The main benefit is putting control of the data in my hands, and making it possible for me to do deep analysis of my work habits so I can make myself more productive in the future.

• Badger - On the theme of personal productivity, this is a webapp that’s designed to automatically create a work schedule if given some basic information about tasks that need to get done and the time that is available to do them. The web-page does most of the work, but it can communicate back to my room’s server for logging, and to trigger physical things in my room for motivation such as the fan art and misc. robotics. It also yells at me using text-to-speech so I know when to change tasks and etc.

• Bool Box - A system for programming microcontrollers. The developer uses a program on a PC to “paint” a Boolean state machine linking outputs to inputs. Simulation is continuous and drawn over the design as it is worked on, so there is immediate feedback. Once the design is finished it is sent to a microcontroller flashed with a VM that simulates the design. The chip will then have the behavior laid out in the design. It’s not practical, but I think it will be fun to use.

• Remake of Miasmata in C++ using SDL

• Several small SDL learning experiments

  • Software 3D renderer (no OpenGL, etc.) based on the math I was learning in class that day. Only supports points and lines. Maybe I will do a voxel thing with it in the future.

  • Full screen Conway’s Game of Life.

  • 3D-drawn (but 2D simulated) Conway’s Game of Life implementation using renderer mentioned above. The cells in the cellular automaton are represented as bumps in a mesh.

  • Glitch - Based on the Conway’s Game of Life implementation from above. Adds mapping of life intensity (measure of change over area) and procedural of generation of sound from the automaton. Makes a nice ambience that I am pleased with.

  • CLIFuck - Basic command-line Brainfuck interpreter.

  • Brainfuckers - I put the brainfuck interpreter from CLIFuck in little bugs that can roam the screen. Eventually I want to implement live-coding and multiplayer. The bugs will fight for resources inside of a mini-environment. Should make a fun little toy.

• Several helpful scripts / webpages utilizing my room’s linux server

  • ideas.php - Shows small thoughts that I’ve had throughout the day/week so that I remember them. I log them into the system using a command called idea that is a simple bash script.

  • randproj.php - Tells me to work on a random project or homework. Helps when I don’t know what to do.

  • map.php - Displays a connected graph of my current projects and the different ideas I have about each one. Ideas that are connected have edges (discrete-math-speak for lines) between them in the graph.

Hardware

• Desktop Turing Machine - I’m planning out this little desktop widget. It is a Turing Machine whose tape is tiny ball bearings. The bearings are moved around with electromagnets. It uses a BEAM robotics circuit to store up power from a solar panel in supercapacitors until there is enough to do one computational step (controlled by an MCU). I envision it just as a pretty thing to watch.

• Fan art - I’ve got a few dozen computer fans that I am mounting on my wall. Their speed will correspond to the rate of my commits to Github, and the rate at which I work through my todo list. I am hoping that it will create a positive feedback loop, making me get more things done by making me aware of the progress I am making.

• Z80 microcomputer from Tranz 330 POS terminal

• Reclaimed server blade

• Tiny wrist-worn display linked over Bluetooth to my phone. It’s just an SMD Attiny84, an RN-42 Bluetooth module, Nokia 3310 LCD, a piezo electric element for tap input, and a tiny polymer lithium ion battery. Will display the time like a regular watch, and also notifications from my phone as well as any other information I care to add. Currently in the drawn-all-over-my-arms-in-pen design stage. Need to find some money to buy the parts.

I’m doing a big hack with this computer I bought the other day at Swapfest for $1. In the process of learning about the computer I discovered that it can be glitched by twiddling the power cord while it is booting. Obviously there’s some corruption of RAM with the partial power loss, and the BIOS is doing memory-mapped text-mode graphics so pretty patterns result. I only have my phone so the quality is poor:

[gallery link=”file” columns=”4”]