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.