I did write that robot simulator I was talking about a few posts ago. The simulator was useful in programming the actual robot, and just looked awsome. I created a nice webpage for it here.
The simulator has been used to help programmers get a feel for writing robotics algorithms, as a program test-bed, and for gathering statistical data on program performance.
Currently it only runs on WinXP and will thrash any non-SMP machine because it heavily relies on mulithreading (student code runs un-checked as a second thread! ahhh!).
If anyone pays me to work on the project (summer research?), I would rewrite the program bootstrapper, which hooks the student’s C code up to the rest of the simulation, to use a C-interpreter (like CInt) so that the application wont thrash older, single-core machines, and will be more easily portable. Additionaly, interpreted code would mean code could be loaded at runtime, so the student doest need to compile the whole simulator togeather. The code could even be viewed running line-by-line in a side window, with break-points and stuff. It could even _modified_ at runtime, which may be a great learning tool for newish programmers. That is, if i get payed to code that! This simulator already has many free (gratis) hours in it… I hope people find it useful.
December 18, 2006
After recently completing the Design I robotics project I got to thinking of other ways to complete the project. One of my peers commented that the project was too “programming-oriented”. Whether you like it or not, you have to program these microcontrollers, but, what a challenge it would be to build a robot that could also complete the course but made from discrete components: resistors, capacitors, batteries, relays, transistors, and maybe opamps, a combination often called BEAM robotics. Possibly that would be a cool EE design project.
Returning to the microcontroller-powered robot paradigm, I was dreaming up ways around the dreaded relative motion issue. By relative motion I mean the robot never absolutely knows where it is, at best it knows it has been X seconds since the last bumper hit or some other event; and as time goes on the relative location information gets more and more inaccurate.
This got me thinking of new input devices. Perhaps a PC mouse could be attached to the bottom of the robot, returning accurate motion data. If this was attached in front or behind of the pivot point not only forward/reverse but also pivot data could be read. This type of input would eliminate the need for bumper stitches, the robot could simply ram into obstacles and would interpret the sudden drop in speed as having hit a wall. This would make the obstacle detection far more accurate as before it was noticed that robots can get tripped-up without the bumper switches contacting.
Implementing an optical senor would not even be difficult to do. I had tried to use an ancient ball RS232 mouse but moved to a notebook mini-mouse (Impression Optical Notebook Mouse, no model number on it?) based off of a ADNS2051 optical sensor module. This module has several PIC-friendly interfaces and can provide pixel brightness, surface smoothness, and peak brightness data in addition to delta_x/y info. Someone at Stanford has developed a very handy open source interface for this chip, available on their wiki.
I look forward to putting this hack together, probably for the Design II project, even though it is totally not necessary.
December 10, 2006
School closing information is time-critical. Knowing you don’t have to go to school today five minutes before the rest of the mob can give you great satisfaction – Wouldn’t it be nice to get a text message as soon as the closing/delay information becomes available? Then you can sit at home, relax, and enjoy the fresh morning snow…
Unfortunately we have had next to no snow recently, so the blizzard photo is courtesy of Richard Harvey (a sweet image of Snow covered A6024 Woodhead Road, into Holme Village, Yorkshire, England in the Winter of 1978).
Back when we did get snow on the east coast, ciphercast and I hacked together this automatic snowday text-message daemon, written in bash (UNIX shell script). It was my first attempt at web parsing and at automatic SMS sending. I realize now that this could be done in python much easier/better but this script may be of interest anyway.
The script runs on a Linux (or Cygwin/Windows) PC that is allways on and connected to the internet (a server), and repeatedly checks the school district website for the text “schools closed” and if/when it is seen, it sends a text message to each of a list of Verizon cellphone numbers by emailing @vtext.com. You don’t even need to open the message as the first few characters give it away: School Closed!
A nice extension to this would be to send to any phone number… maybe the script could detect what phone company owns the line, and select the appropriate method of sending the text message, as right now it only sends to Verizon customers.
Of course this can be adapted to report any kind of change of status in a web page. It is an example of the power of automated text messaging.
December 9, 2006
Tonight I managed to hack togeather something I had dreamed about for a long while: A robot’s motion is controlled by the notes played on a tin whistle, or by human whistling. This was accomplished in only a few hours of hacking by modifying a basic console guitar tuning app for linux called String (part of gString). The tuner normally picks out the loudest frequency and tells the user what note it is. I just changed it to instead send commands over a serial cable to a PIC microcontroller powered robot. The robot now can be driven around, accomplishing various tasks, simply by playing or whistling the right notes while in the same room. I will investigate the possibility of putting the frequency detector on the robot itself, rather than on the PC, however ordinarily this would require far more processing power than an 8-bit microcontroller has got.
Here is an executable compiled for Kubuntu Edgy.
And here is the guts of the C code for the actual robot.