Chris Flesher's Insane Robot Blog

October 1, 2006

I've been looking at ways to upgrade the networking system for our vehicles. Right now I'm looking at using Python's twisted module to create a prototype and then using ACE (the C++ equivalent of twisted) to make our C++ version. There is a really good article on networking here that got me pumped about this stuff. Right now I'm going through the twisted tutorials to get an idea of how to write our networking code.

I also drew out a diagram of all the crizzap we'd have to do to compete in IARC and it looks like quite a bit of work (most of this work is due to fail-safe measures and redundancy in case the helicopter decides to die on us). My best idea for a starting point would be to get networking working along with the IMU on some type of small embedded platform. We could fly the helicopter with the Futuba and record data. I'd like to get our networking upgraded / logging working on the ground vehicle first though with a Python prototype.

September 30, 2006

One of our alumni, Nick (the guy who started our IARC group) returned to the trailer today. He gave some interesting tips on how to start developing our own IARC project. I'm really interested in networking right now (our networking stuff is kind of hacked together ), so I asked him for his ideas about that. He suggested looking into CORBA, a client server message passing model that is already mainstream and available in C++, Python, and a host of other languages. I'm probably going to start looking into this CORBA stuff before working on logging so we can get our network structure looking better (with seperate processes for frontend, the devices, control, logging, and playback instead of just frontend and backend).

He seemed to be pretty pumped about making a board that had an IMU, GPS, and a microcontroller for flight control all on one board. I'm in disagreement with that (I'd rather just run cables to our sensors so we can change out our sensors easily), but he was hinting that he wanted to build one in his spare time, in which case I wouldn't mind using his work. Chander and I were discussing the computing platform we should use... right now the best short term solution looks like it's going to be the Gumstix until Chander gets his ARM research board (we're not sure when that will happen) or Nick decides to put some time in and make a badass flight controller board (he says he'll be busy for a couple months). I'm really hoping that Augistine gets his grant for his four-prop helicopter so we can do some joint development on some kind of embedded platform...

September 18, 2006

I found a JAUS repository this moring that I hadn't been able to find before. Apparrently it is written in both Java and C by some members from the Universtiy of Flordia for the DARPA Grand Challenge. Here is the link to their Trac Wiki. They use SVN too so this should make it easy for our group to get and play around with. Hopefully we can somehow wrap their C code to be used with Python and / or Labview.

August 31, 2006

Since we are going to have a ton of people in the trailer on Saturday with little or no direction I've decided to post some SoftwareChallenges to help out our code base while simultaneously getting these new people up to speed (if they want to join the IGVC team). There are currently four challenges that represent some major components of our current code base: the simulator, control systems, computer vision, and drivers. I think these challenges are a little ambitious for people coming out of high school, but then again the people that can solve these kinds of problems are the ones we want on our team anyways. Take a look at them and tell me what you think.

August 14, 2006

Ok so this is really funny... Type in "IGVC 2007" into google and what do you find? The second link on Google is our VisionAndScope page that is half complete. I guess I should probably try to make this page better. I don't know why we get such good ranking on Google without trying... Oh another one is "3dmg imu" and our report from last year comes up instead of the company that actually sells these things... This is really hillarious. If you guys find some more post them here:

August 13, 2006

I was trying to close some of the tickets for the simulator today. I didn't actually close any but made some decent progress on the config file parser and the udp send/recv stuff. Right now the only functionality you can play around with are in two programs: visualization.py displays a robot from the config file and mapBuilder.py allows you to build maps. You can also run the test code from udpmonitor.py and config.py to make sure they are working.

Hopefully sometime next week I'll get the simulator working again so you can move the robot under manual control. Then maybe I can finally get this freggin' record / playback working and we can have a blasty blast of a good time. Oh be sure to check out the format for the config files I put up. Basically everything is in include files and I moved the s12 config stuff to the devices.xml file. I kept Vishal's .config files up there to compare so we can finally hammer this config stuff out.

August 12, 2006

I got to the trailer kind of late today -- nobody was here so I decided to take a break from this logging stuff and work on an idea I've been wanting to implement for an AI system. The concept for the system is based off of NEAT (Neuro-Evolution Through Augmenting Topologies), an algorithm developed here at UT. The basic idea behind the NEAT algorithm is to use genetic algorithms to modify a neural network, measure the performance of the network in the real / simulated world, and repeat. I really like "innovation" system they have for modifying the network topology but I really don't like the idea of using neural nets for AI very much because they seem to be too inflexible if you want to adapt them. Neural nets are too sensitive to parameter changes, I think.

Using a markov model in place of NEAT's neurons might result in a better AI system. Fortunatly I have some code I started for NEAT and finished writing the testing interface today. You can check out the code for this in the igvc2007/trunk/sim/hmm_neat/. Right now the circleSim.py records the state of a simple discretized system (a point moving around a circle whose x,y position is represented as a location on an x-y grid). The neat4.py code was some stuff I wrote to try to implement NEAT in python. Right now you can only generate a genome and mutate it.

July 23, 2006

So I had an idea today about our goals for this summer. Yesterday Andy and I were talking and we both realized that we currently have several fragmented tickets that people are working on but no real plan to merge the seperate pieces by the end of the summer. I think it's good to break a large project into demoable phases because you greatly reduce the pain of system integration later on. If you take a look at our tickets you'll also notice that most of them are about the essentials: sensors, communication, and infrastructure. With that in mind here is my suggested plan our group this summer.

We should get Raslow running with all of the new sensor and communication code, be able to record data to an XML file, (and maybe even play it back with the Python XML playback program). We could set up a program to drive Raslow in manual mode with a keyboard and then test our new code out. With all of the data we could develop control and sensory algorithms more easily next semester because you don't need a pysical robot running to test stuff.

We have about 5 weeks left of summer and I think if we can get all of our code written for this in something like 3 weeks then we could test it out on the robot in the remaining two weeks. Tell me what you think.

• Great Idea, This goes along with the ticket:29 and probably another future ticket ~Andy,

July 16, 2006

Today I really wanted to replicate the PCA-SIFT code using our OpenCV development environment. My original strategy was to translate all of the original author's custom api functionality to OpenCV. However this turned out to be a debugging nightmare! The author's code ran on Linux so I had to run it on Linux, check some values, and then boot Windows up and see if I could replicate the results. After a while of looking into the code I finally figured out that the author was using a floating point representation (0.0 - 1.0) for his image intensity and OpenCV was using an 8-bit representation. The OpenCV was rounding off some values so I couldn't really tell if the inconsistencies were comming from rounding errors or something else I was doing.

Finally I gave up and just made an OpenCV wrapper for the original source code and I am getting the original results exactly. Now I'm going to try to replicate his results using an IplImage with floating point accuracy. This will be a helluva lot easier to debug because I can compare my algorithm with the original algorithm on the same machine with a (hopefully) very similar image representation.

Oh and if you haven't gone to the trailer lately I went on a cleaning binge and you can actually find stuff now! It's great. Anyways Flesher out.

July 9, 2006

I can't pronounce bacaruda. After several hours of searching I finally found our theme song from IGVC 2006. Ba ba ra ra cu cu da da!!!

July 8, 2006

I found a really neat debugging tool for C++ today. It's the AMD Code Profiler. I was looking for a good way to see how my vision code is performing because it currently takes about 18 seconds to run the Keypoint code and I want to get it down to around 1/30th of a second if possible. Most other code profilers are commercial and fairly expensive (see the Wikipedia page on performance analysis for an overview of all of the profilers that are out there). If you're lucky enough to own an AMD processor then you can use this tool.

Another approach to code profiling would be to use aspect oriented programming to write your own profiler. At the end of every function the injected aspect code could querry a timer to see how long it took to execute a method. This approach should would work for any processor / operating system.

So after looking at the performance analysis about 83.87% of the total processing time was spent on my program, RasVision.exe. 38.84% was spent manipulating std::vectors. I think this is because the original code does not resize the std::vectors to the proper length when they are created so there are a lot of unneccesary resizing, allocation, and deallocation operations going on. This is a pretty common optimization problem in the gaming industry.

So to recap, make sure you resize your std::vectors to the proper length. If you want to write your own profiler for your C++ program you might consider using Aspect C++. Otherwise if you just want to do C++ code profiling you should throw away your Intel chip and get a new motherboard with an AMD chip. It will end up being cheaper than buying Microsoft's or Intel's code profiler.

July 2, 2006

The simulator is barely working now with the new XML config file. It's starting to become a pretty major overhaul... Fortunatly I have been able to reuse alot of the guts from last years code (most of the sensory, map building, and drawing functions). There is still quite a bit of work to do however.

The structure of the new simulation has been divided into two parts: the simulator and the visualization. This is so that we can reuse the functionality of the visualization with or without the simulator running. These two programs share no common variables. All communication will be through message passing so that when we switch the visualization over to the real robot there won't be any problems setting everything up. The visualization will eventually have different modes depending on what you want to look at. I called these modes "Contexts" and so far there are three of them:

• Replay from file -- Replays the specified XML file
• Replay from buffer -- Replays from a buffer (right now a 5 second buffer at 60fps)
• Control -- Allows you to see what's going on in the world and control the robot using the keyboard

Input to the simulator is pretty configurable... Right now the only source of input is the keyboard but it wouldn't be too hard to add something like a joystick later. The keyboard settings change depending on what context you're in. For example if you're in the Control context you'll have key bindings to robot actions and in the playback contexts you'll use those same keys to step through events in time.

I added some ideas to the KillSwitch page. We really should use a NES light gun for our kill switch. Just take a moment to reflect on how awesome that would be.

June 29, 2006

Added the vision and simulator projects to source control. If you're checking either of these projects out for the first time be sure to read the README.txt files to learn how to set up these projects on your computer. And of course don't be afraid to edit these readme files in case I left something out. The simulator is just a copy of the one we used from last year. However the vision environment is totally new.

This year I added some detailed instructions on how to set up the vision development environment (setting up OpenCV for the first time can be a royal pain in the ass as several of us have discovered). Also the code is a lot cleaner. All of the image processing happens in a user defined callback function at the top of main.cpp. All other image processing functions are stashed away in other .h/.cpp files. Right now the only thing this program will do is load an image, perform any image processing from the user defined callback (which is currently empty) and wait until you press a key. This version is excelent for anyone wanting to start up their own OpenCV project.

I'm thinking about adding threads (from the C++ boost library) to the current program because whenever the RasImage::InputStream is created it will just sit there in the constructor until a key is pressed. This is kind of annoying if you want to have anything else running (like keyboard input) while the image processing is going on.

June 28, 2006

Today I made my first Wiki page and became a true manly man!

So I've been looking at ways we can implement our own VSLAM algorithm. The VSLAM algorithm has three basic parts. I'm sure there are more out there but currently the only one that I know about is Evolution's VSLAM algorithm (Evolution is a commercial robotics company... I'd use their algorithm but unfortunatly it is closed source and I think we can make ours better anyways >:P). First the reliable image points from each frame are found using a Keypoint algorithm (David Lowe's SIFT). Next the points are tracked from frame to frame and combined with odometry to get image disparity (this allows us to determine range). Finally the range measurements from the past few measurements are fused to determine the noise of the range measurements. Noisy measurements are filtered out and the final result is a 3-D range measurement of the robot's surroundings.

I've been collecting Keypoint source code for SIFT for the past few days... Started writing our own keypoint algorithm for OpenCV and used some of the code from last year's IGVC to read images from cameras, images, and AVI's. Right now I'm modeling our Keypoint algorithm off of PCA-SIFT -- I think that PCA-SIFT gives a better representation of Keypoints than the original SIFT algoirthm.