Alex's SLE Project

Summary/Video:

A tour of my SLE workspace from Alex Leutenegger on Vimeo.

Much to my frustration, I don’t instantly know how to do everything. So, because of this, I’ve spent a lot of time learning how to do things this past week and learned how to effectively do three fundamental things. I now know how to read digital input with a microcontroller, how to set digital output with a microcontroller, and how to use a microcontroller to drive an h-bridge (motor control circuit).

While none of these tasks alone may seem particularly impressive, together they encapsulate almost everything I need to know to control my robot. Additionally, since nothing I’ve done has worked the first time it was turned on, I’ve had to problem-solve and debug everything I do to accomplish even the simplest of tasks, which brings tons of implicit meaning these tasks.

For example, I thought a voltage regulator circuit that I had made was broken. Instead of outputting 5 volts like it was supposed to, my multimeter read that it instead outputted 6 to 7 volts. After replacing each component and checking my connections a million times, I realized that my multimeter may have been the problem, which left me with the question: “how do I test a multimeter.” To answer this, I looked around for something that was constant voltage, discovered that a USB port outputs a constant 5v, carefully tested my USB port, got a similar reading of 6 to 7 volts, and confirmed that not only my multimeter wasn’t working, but also that my voltage regulator circuit worked. In the end, it turned out that my multimeter needed its batteries changed.

Trivial stuff like this has been tripping me up all week. As a quick list, I’ve discovered these things to be common issues when breadboarding circuits.

• Polarity sensitive components hooked up backwards
• Component leads not pushed into contact with the breadboard, especially with my microcontroller
• Leads squishing into each-other, causing shorts
• Power supply not turned on (seriously)

My breadboard: the root of all evil

Anyway, I’m starting to excitingly move past microcontroller fundamentals and into the realm of making stuff wheel around and bump into things! Today, I worked on mounting a microcontroller and a motor control circuit onto a piece of perfboard:

The top of my perfboard: so unassuming

The button of my perfboad: ugh, a rat's nest

Naturally, when I first turned this on, it not only didn’t work, but started smoking. I now have a project for tomorrow.

Between my now and my last post, I’ve decided to cut back on the scale of my senior learning experience. Cheaply creating my own swarm bot platform implies doing tons of things that could easily count as standalone projects, including writing a low level mesh network protocol and learning about distributed algorithms. While I feel that I’m capable of doing these things, I just wouldn’t be able to do them in span of my SLE.

So, instead, I’ve decided to focus on creating just one robot, with the ultimate goal of efficiently solving a motion planning problem. In this problem, I will start my robot at a starting point point, S, and then move to my destination point, D. However, the space between the two points will be filled with rectangular obstacles, like so:

As I’ve found in my initial research, there are two major ways to approach this problem: either through grids, or through geometry. With a grid based search, my robot would overlay a grid on the configuration space, and then test each grid box for being passable. Then, with this grid, it would apply a search algorithm, like A* or Dijkstra’s algorithm to find the shortest path. However, this solution does not yield the most optimal shortest path, as it limits turns to conform to geometry of the grid.

For a geometric solution, a visibility graph can be used to reduce the configuration space to a graph of each possible path movement through the obstacles, and then a shortest path can be found with a search algorithm like Dijkstra’s. I spatially and “holistically” understand this method, but I’m still cloudy about the specifics, which are pretty important.

Anyway, speaking in terms of physical things, and real plans, and real schedules, and not theoretical gobbledygook: I got the parts I ordered from Sparkfun today!

I’ll post pictures tomorrow, but for now, here’s a quick inventory of the cooler stuff I got:

• ATMega328 (robot brains)
• Ultrasonic ranger finder (robot eyes)
• Really nice gearmotors (robot legs)
• Wheels and encoders (I can’t really think of an anology, but maybe: “robot feel-where-I-am”s?)

Sparkfun is a really nice company. For someone who has a limited experience in electronics, Sparkfun makes the process easy and non-intimating. I’m not an electrical engineer, and for now, an arcane PDF datasheet doesn’t address my concerns as well as Sparkfun does.

Sadly, I still need a USB compatible AVR programmer to really get started. Tomorrow, while I wait for one rush-shipped (15 bucks, ouch), I’ll continue to bone up on my C, write another blog post (with pictures), and read more of my graph theory book.

Compared to the other languages I’ve learned before (Ruby, Java and Actionscript), C is pretty tricky. Thankfully, The C Programming Language by Kernighan and Ritchie is a great book and makes it less of a pain.

When given a seemingly trivial problem like writing a hex to decimal converter, I could probably crank out a couple line of Ruby without much hassle. Ruby even has a converter written into its standard library. However in C, things aren’t as simple. Due to my relative inability, it took me most of an afternoon to hack together a working solution.

#include <stdio.h>
#include <string.h>
 
int power(int e)
{
	int i, n;
	n = 1;
	for (i = 0; i < e; ++i)
		n = n * 16;
	return n;
}
 
//hex to int, given char array of hex string s
int htoi(char s[]) 
{
	int l = strlen(s); // -1 comes from excluding \0 char
	int i, n;
 
	n = 0;
	for (i = 0; (s[i] >= '0' && s[i] <= '9') || (s[i] >= 'A' && s[i] <= 'F'); ++i) { //loop as long as char is int of A-F
		if (s[l-i-1] >= '0' && s[l-i-1] <= '9') {
			n += power(i) * (s[l-i-1] - '0');
		}
		else {
			n += power(i) * (s[l-i-1] - 'A' + 10); //sets base at A, and then +10 considering A = 10
		}
	}
	return n;
}
 
int main()
{
	//test cases
	char h1[] = "A0";
	char h2[] = "4235";
	char h3[] = "BF4334";
	char h4[] = "AAFF47";
 
	printf("%d \t %d \t %d \t %d\n", htoi(h1), htoi(h2), htoi(h3), htoi(h4));
 
	return 0;
}

I’m scared for when I get to pointers.

Well, here’s the first of (hopefully) many blog posts regarding the progress of my senior learning experience!

For those of you from outside the RMSEL community, a senior learning experience (SLE) is one of many cool independent learning opportunities that my school provides. Seniors are given a long period of time off from normal classes – from the 22nd of February to April 6th – to study a topic that interests them. For my particular senior expedition, I’m going to make some cool robots.

By the end of this experience, I hope to be able to answer, if not strongly address, three overarching guiding question, which are:

1. How do I successfully solve problems in physical and virtual systems?
2. What makes effective robotic design?
3. What tools, skills, and theory do I need to create effectively designed robots?

To accomplish this, I will learn the basics of embedded C programming and electronic circuits to ultimately create “swarm bots” that communicate over radio-frequency modules. For a more in depth look at my initial plans, I’ve uploaded my SLE proposal here.