AVR Introduction Class @ Hive76

Remember that this weekend I will be teaching an introduction to AVR micro controllers class at Hive76. So far I'm ecstatic and, if it goes well, will plan a series of lectures and will redesign a more suitable kit.

Building a 3d Printer.

Some people want a cool new toy for Christmas. Those that are a little older hope for some special jewlery, a new sports coat, or possibly the keys to a nice car. Me? I dream of parts for projects.

Most notably an attempt to build a sub-$300 3d printer.

Fixed intermittent Internet on Beagleboard

So I've been suffering from a problem of intermittent Internet on the Beagleboard. It worked twice in it's history - just long enough to install LXDE and a VNC server for it (fyi, I'm hating the LXDE, at least for his application), and SSH so I can remote in easier. The problem was that Internet otherwise refused to work.

The problem, it turns out, stemmed completely from something I did when setting up the SSH. One of the steps I garnered from some directions (and almost made it in the upcoming Beagleboard walkthrough) was to add this command to a startup script, enabling SSH on boot up.

route add gw default 10.10.10.10

This made my computer the default route gateway for connections, which in theory would allow the ssh to work. Well it turns out the ssh works without that line, and that the line was telling Linux that Internet connections go through the usb0, which is not how it works.

Currently I am looking into brctl (bridge-utils) in order to give the beagleboard internet via my Laptop's wifi (thus being able to bride it online anywhere my laptop goes), but it seems that wifi makes it a pain in the butt to do. Something to add to the to-do list I suppose.

Incoming Beagleboard...

As some of you may know, I am in the process of doing a write up on the Beagleboard - from deciding to buy one, to purchasing components, to getting Ubuntu 9.04 up and running. As of now, I have Ubuntu working on a 2 gig SD card with USB networking, VNC via LXDE, and SSH working on boot up. Cool! I am having trouble duplicating my efforts on a 4 gig card, and since I just got my 8 gig card in the mail, I'll be redoing it all on that card as well. I want to make sure I don't miss anything, so the write up is postponed until I confirm each step.

So far - I'm impressed and in love with this piece of hardware. But since I'm shy a DVI-D compatible monitor, I'm limited on what I can test immediately.

STK500 is fried. I admit, I teared up a little.

Power surge- fried my STK500. The fuse is smoking any time I plug it in and switch it on. I'm shopping for a new fuse, but the markings were burned out. According to some helpful STK500 owners in the IRC chat #avr on the Freenode Network, the markings on the chip read ST label: C525, with an ST center top, ME in the middle, E at right top, and C525 center bottom. A quick search turns up (surprising, since I expected no hits) that the smoking bandit is a slow blow fuse, rated for 24V (makes sense since the power plug is rated 10-15 V) @ 6 Amps.

6 Amps?! How the hell did I blow this thing!?

Anyway, I'm buying a new fuse - the 6A one and a similar 2A one (smallest I could find that was a slow blow @ 24 V). Let's hope this can resurrect one of the most useful tools in my arsenal.

EDIT: It appears that the broken component might be the chip next to it - a bridge rectifier. Easy fix. I ordered LadyAda's USBtinyISP since the STK500 can still be used as the best target board ever (for every AVR). I should have it next week. I'll still try to repair the board, of course - it's a backup plan.

AVR to Ethernet

Not an uncommon project - I am trying to get an 8-bit AVR Atmega168 online. I'm using the notes found from others' previous projects to guide me. Ultimately I want to create a simple cut and paste module to be able to cheaply include internet capability to a number of other projects - more to come on those in the future.

Here's a quick pick of the ENC28J60 and Magjack (with Sparkfun breakout board to make my life easier.

Unfortunately I'm finding I overlooked ordering key components, so I'm not sure if I'll get it up and running by this weekend. I'll be working getting the basic, ping-able server up and running on AVR tonight . I'm hoping my cheap hacking around with the circuit will allow it to still work.

I also feel like a fool - I may have accidentally fried my STK500 (don't ask) and will be without an AVR programmer for awhile - particularly devestating since I'll be teaching a class on AVR programming in the near future.

From the lessons of peers

FUBARLabs has twice a month a Python study group, where we teach other various tricks of the trade in Python and cover many of the all-too-cool Python modules out there. All skill levels are welcome, but those of us that regularly attend tend to be regular code monkeys. Here's some of the things we've covered (so you don't think I've been lazy - ha!):

AVR class and a Robocode Challenge

I've been quite busy. I've been volunteering BETA testing the new FIRST robotics controller and teaching high school students how to program their robots in Java. I've also been working heavily with people at FUBARlabs to help turn it into self sufficient hackerspace (easier said than done). I've also been helping FUBAR design some classes...

Happenings at FUBARlabs

As I've mentioned before, I have been helping start up a new hackerspace in central New Jersey - FUBAR Labs. We're still filing for a non-profit corporation status, but we're beginning to move ahead with a number of plans, some of which I came up with or have been put in charge of. Here's some of the cool events I'll be working on for them.

PAC Google Code

PAC is taking shape. It has a google code project page, and will hopefully soon have some code up for people to use. I also plan on using PAC for a few upcoming projects, so this is quite exciting.
 
PAC on Google Code
 

The future lies in hackerspaces

Not even two weeks prior to this post, the last I read of hackerspaces was one of two things. It was either the ideal description of a place that seemed to have goals too lofty to believe, or a random place where a cool, 15-minutes of internet fame project was hosted - usually a major hackerspace like NYC Resistor. For some reason I had been set in the belief that the major hackerspaces were few, rare, and far between, capable of surviving only in special circumstances and large cities. Still more I had the pessimistic belief that the lofty goals and ideals of a hackerspace - existing solely to push the education and application of technology for common people of all skillsets - to be useless. While my own interests cause me to greatly anticipate any way to further educate myself on technical matters, rarely did I see the same diligent spirit in others.

Imagine my surprise when I found out that I was completely wrong.

On PAC in application

There has been a slight change in the manner of how PAC will work. While coding it I realized a weird thing - when the slave (MCU) can't talk until the Master (PC) requests something, there is little to no difference between sending a message and receiving one.

PAC Quick Update

A little bit sleepless (particularly bad due to my weekend trip to Conneticut from New Jersey tomorrow), so a quick PAC update to try and tire myself out.

I finally got around to doing more work on PAC, mostly through the downtime from helping out others at a Python study group at a local hackerspace (of which I'll go more into detail in a later post). My original whiteboard drawing has been kind enough to act as a guiding force, albeit not the actual outline for the full implementation.

PAC - Python / AVR Communication Library

I love making neat little acronyms. And so begins the first post about PAC!

Today I will be discussing my thoughts on the anatomy of a proper command message.

Where I stand

I've disappeared of late - mainly to finish school, hunt for jobs (with unfortunately no luck) and work on some projects.

I am currently working on, and will soon expand upon, the following projects:

Unnamed Product

I am developing a product, meeting with SCORE counselors, and going through the motions of starting up a business. As of now I do not know my endgame here - selling the product off to an established company or starting a business fresh, I'm not sure. Currently I am in the prototyping phase, with hope-raising success on several ends, and a laundry list of to-do's. I might post some information about this from time to time, but for now I'll be keeping it under wraps.

Python/AVR Communication Library

I mentioned it before in the form of a Python robotics library, but then immediately got distracted with school work. Well, now I'm finding myself with plenty of free time. The project will focus upon using AVR micro controllers for their relative ease of use and low learning curve for new comers, and the truly inexpensive price to starting. I will no longer focus on robotic applications, though a set of robotic commands might sneak their way into this, as I plan on using it to control future robots. It is more of a fleshed out, ready to go rapid development Python/AVR communication library, where the computer running Python acts as the master.

Even an Arduino (I only have Boarduino, as my Arduino was stolen along with a number of other things) compatible version might rear its head. Maybe.

Since I'm rebooting this project, I have a short but oh-so-important to-do list for this project right now:

1. Find an AVR library to hasten development and support more than one AVR chip.
2. Cannibalize my old code from the project and determine what works - and what doesn't.
3. Create a standard of common commands that will be commonly used, and make creating new commands a cinch.
   

Robotic Vision

This project aims to be a super simple, octagonal robot base that I will be mounting my EEE PC and a web camera too. I will be trying to teach myself OpenCV and computer vision in general, either through OpenCV's Python or C++ version. MATLAB may also be used. Given that I have very little C++ experience, this may be the right amount of interesting and challenging. MATLAB is a pain because my computers all currently run Linux - leaving me with no known method of acquiring video from a web camera or other source and giving it to MATLAB.

The project is on hold because two separate companies completely screwed up shipping in two different ways. One sent my Asus EEE charger (lost the first two, oi!) to the wrong house, and I am now patiently awaiting another. The other company held onto my servos for over two weeks before finally contacting me, telling me that my credit card didn't go through because of a mistyped address. Who knows why that took two weeks. Once one or the other shows up, it's onto the project's to-do list:

1. Design a servo mount to go with the base and servo. Design a pan/tilt device to go on said base for the web cam.
2. Build a quick power and battery circuit for the servos - nothing fancy. Bare minimum stuff.
3. Build a servo controller for 4 servos. I plan on using an AVR (big surprise).

From there, it's exploring computer vision! This will also act as an excellent platform to test my Python/AVR library.

Modular Robotics Platform (MRP)

Note: This is actually a repost of something from an older blog, just to catalog one of my projects. This writing is old, written when I was newly a college senior. I've learned a lot since then, and can probably do this project in half the time, ten times as well, for a fraction of the cost. Such is the benefit of having hindsight.

The Modular Robotics Platform (MRP) is finished (and has been for some time now). My project group (three of us in total) are currently working in writing the project documentation required for this school project. I spent the summer working with this team in order to develop the prototype, and it is something I am quite proud of. It isn't perfect, and I can rally off a list of things I would do different. The important thing is that the robot gets the job we set out to do done.

As a recap, the MRP is designed to be a modular (duh) robotics platform that can be used in robotics research and educational platform. Mechanically it is designed to be easily modifiable, electronically it allows for quick sensor and circuit design and implementation/testing, and in the realm of computer science (which was my main focus, although I worked on a bit of everything) the MRP allows for the quick development of programs and even the rapid replacement of its entire operating system. All of this for reproduction price of $1200-$1500, though I know several ways to cut price significantly.


Here's a list of some features:

Mechanical:

1. The drive train is designed to accept either a motor or a servo by just sliding it in. The drive train can also be attached at any point on the frame.
2. The frame is made from Item, a brand name extruded aluminum. With special connectors available from item, you can practically connect anything to the frame at any place at any angle, maximizing mechanical modularity and expandability.
3. The robot is big enough to handle simple out doors obstacles, yet small and light enough for storage and being carried around by students

Electrical:

1. 15 Digital I/Os that can be expanded by advanced users to over 150 I/Os, 5 ADCs, control of up to 8 servos simultaneously and four 12 volt/3 amp max motors.
2. Rechargeable battery means you can recharge while working on it. Battery also lasts for 1.5 hours under standard usage.
3. Fuse block design keeps all parts isolated and safe from blow outs.
4. AVR Subsystems (to be explained later).

Computer Science

1. TS-7800 ARM9 Embedded Board @ 500MHz. It runs Debian Linux, booting off of either its on board flash, an SD card (which I used for this project) or a microSD card.
1. This also means that users can not only take their code with them, but can also literally swap out entire operating systems in a matter of seconds.
2. Small C library developed to allow easy user control of the robot's hardware.
3. Modification of some aspects of Debian Linux to make it more suitable for robotics applications.

The AVR Subsystems

One of my favorite features of the MRP was its AVR subsystem.
The AVR subsystem consists of 6 AVR chips. While in dedicated positions on this rendition of the MRP, I would make them more open on future versions. Each AVR pictured is an Atmel168, a powerful micro controller for which there are tons of projects on the web for. Easy to develop for and powerful, it can be used for any number of calculations. The only vertical chip in the picture is considered the "communications" chip, which talks to the MRP's main processor via serial. This chip communicates, passing either small commands or receiving simple values in return from the other 5 AVR chips. For this particular PCB board, we've assigned a "default" usage for these chips. Four of the chips are each dedicated to a single quadrature encoder (built into the drive train we designed). These chips keep count of each of the encoders and, when requested, return their current value or reset the counter. The fifth AVR chip is a stepper motor driver circuit, so a stepper motor could be smoothly controlled separate of all processes.

The AVR subsystem was done using socketable AVRs in the hopes that students or researchers could, if needed, pop them out of their socket and reprogram them to do another task. The PCB design did not leave this too open ended, but future renditions of the MRP should.

The Final Word

I learned an obscene amount on this project and loved every minute of it. Will there be future versions of the MRP? Who knows. As of now it won't be used in the future robotics classes at WPI, but that was a long shot anyway. I am proud of the work I did and think I hit a home run with the project.

Ant-like hexapod

Very cool control of a Lynxmotion Phoenix Hexapod base. It gives me half a mind to buy new servos for mine. That is, if I had the tons of money required to do that.

Particularly impressive is the demonstration of having control over a chosen center of rotation and holding that there. Very fluid movement, as well.

Client/Robot Control

Particularly when dealing with smaller, light weight robots, the issue of processing power in such a small package becomes problematic - particularly with budget in mind. Recently, netbooks (such as my beloved EEE PC, the original one with 7 inch screen) became a relatively cheap solution. Capable of being mounted on robots at least the size of a remote control car, they can provide a full OS of built in control and up to 2 gigahertz of processing power. Never mind that the "reduced" and "cheap" cost I'm talking about is still in the $200-$400 range.

Still, small development boards with tremendous processing power are becoming more popular, particularly with the dropping price and rising power of the ARM architecture. My own experience with the TS-7800 during my senior project provided a low cost, and surprisingly capable board that controlled my robot. Recent discoveries, such as Tin Can Tool's sexy, sexy 40-pin DIP Linux Board provide still more packaged processing power, even lower at $150 dollars a pop. Gumstix provides even more solutions starting as low as around $100.

But there is still a size limit, and the omnipresent requirement of a limited budget as well. The requirement becomes necessary, then, to off-load the processing from the robot to a networked "client". This client, typically another computer, has more processing power and can control the robot from afar, much like a human controls a remote control car.

My current and final robotics engineering class (Unified Robotics IV) at WPI is an excellent example of this. In order to produce affordable platforms for student use for the course, without sacrificing significant capabilities, we are using a serial-to-wifi bridge that goes from an Atmel Atmega644p micro controller to our computers via a LAN. (It is worth noting, however, I took a different route and merely used my bluetooth DIP module to connect to my robot, mostly due to my own impatience for the finished platform.)

Using this, the students can use a Client Framework with the unleashed power of our workstation computers (all 2.4gHz PCs) for our robots. This includes the integration of programs such as MATLAB and video processing programs for use in the lab.

Why do I bring this up?

The Framework has been the problem of late. The original provided Client Framework - made in C++ - was disorganized and unfinished. Several students, myself included, selected our favorite languages and began designing our own. I chose to create an object oriented Framework in Python. Initially I wrote the client framework out of haste and necessity. I have had a blast designing the framework, taking in all the implications of having an object oriented modular approach to designing robots. The possibilities of future projects seem almost endless, and I plan on exploring this side project after I graduate from here.

The Pitch

My goal is to create a simple object oriented python robot framework in which it is easy to develop a Robot-side framework to match it. Case in point - my current C robot-framework developed for the Atmega644p. A very probable future-case-in-point - my iRobot Create and its Python interface.

"Aren't there already projects like that," you ask? Yes, I am well aware of Pyro and Pyrobot, and will discuss those in some other post. I believe I am still bringing something new to the table.

The Framework will have three primary goals.

1. Create an object oriented approach to a viewing a Robot. This framework itself has need of accomplishing the following goals:

• Provide simple, one-command interface for simple functions of the Robot. Turning, going straight, etc.
• Allow the robot to determine where it is from sensors.
• Develop and expand Map.
  
• Simple responses such as bumper response.

2. Allow for control of one or multiple robots at once via an easily used Python script. Each robot maintains their own connection, allowing for this to be done seamlessly.

3. Allow creation of an AI object - each with their own set of goals, behaviors, and reactions to situations. The AI object is given a robot or set of robots to control.

With the Framework having a standardized approach, this can allow AI research (or simple games, since whatever work I do will be trivial to current AI research) to be easily explored with little to no work holding back the initial exploration.

For now?

I will be focusing on my coursework, of course. The framework will be put together primarily to accomplish the goals of laboratory exercises in Unified Robotics IV. The work I do, however, can be expanded upon and be used as a launching point. There are already numerous pieces of code to control the iRobot Create - some I wrote for the TEPRA Autonomous Robot Challenge (which I did well in) and - and more from projects such as pycreate. I can easily adapt this to the Robot Framework and use the Create as an easy low-maintenance platform for learning navigation and AI.

As always, more to come...

Final Project for Unified Robotics III

So yes, this is a repost from my older blog, but I wanted to preserve this in the new blog. On top of that, I think it's still cool. A little bit of background this assumes you know - I am (for now) a student at Worcester Polytechnic Institute (WPI) going for Robotics Engineering (RBE). There are four primary robotics courses for RBE - the Unified Robotics courses, I through IV. The following is a post about the final project for Unified Robotics III:

~~~

Not only a demonstration of my lack of video editing skills (the false start, sorry about that), but also the demonstration of the final one week project for Unified Robotics (RBE3001) at WPI. The robot arm must detect and localize the block while it is moving on the conveyor belt, determine the inverse kinematics to move the arm into the right position, and then pluck up the block. Once it lifts the block, it determines which of two possible weights the block is, and then drops the block into the correct bin.

Development was done on an AVR Atmega644p with custom control board for the robot arm. The arm itself is also custom to the class.

Lifting is done via an electro-magnet.



~~
And a classmate's project:
~~

What is this here for?

So recently I began work on a school project that I realize can, very easily, be branched out into something bigger. On top of that, I am beginning to realize that when I move to a 9-5 job (where ever I end up) I shall probably have far more time than I do now as an engineering student. As such I am planning on exploring parts of robotics I haven't been able to dedicate as much time as I would have liked.

First off - who the heck am I? I'm an engineer (or will be when I graduate this may) possessing an undergraduate degree in Robotics Engineering. I'm also a huge geek who loves doing technical things for fun. I think that about covers that...

More to come later.