Project COMRADE

What year is it ?

One member gone to never-never land.
Another one works like mad these days.
Yet another one is writing code to signify a failed build in exotic ways.
The last one is writing stupid things like a LOGO IDE.

Sounds like a good time to restart COMRADE, doesn't it?

Current Mood: devious
Current Music: Atacama - Medwyn Goodall

Oh well, yesterday, we demonstrated COMRADE for the last time at a college-level project competition (NPPC 2004). Though COMRADE will continue, there'll be none of these competitions anymore. A major spur they were, and I, for one, will miss them.

Since everybody else is too busy, thought I might make good use to update our status. Everything except the webcam has been mounted and all the data is coming in successfully. Not only that, the evidence grid structures and the appropriate update functions are ready. They come in two flavours:

• Mrinal's dynamic obstacle avoidance update function


• My long-term integration-over-time update function.

Current Mood: cheerful

It is rather strange that for the amount of work actually completed in the last few days, there's been no post. It also is a sign of my joblessness that I've gotten down to report their work, of all people :-)

Stepper motors are working, and JD has mounted the sonar modules on them. As I speak, Mrinal, Sharad and he are testing various speed and step configurations...and the stepper motors are merrily doing jingly salsas.

Mrinal fixed a broken automake and I have (for lack of better things to do) have reorganised the CPC into separate directories. Waiting for Mrinal to link in his own code and write the compile script. Also, Mrinal reconfigured the webcam driver so that now we're getting better images. Not ideal, but it'll do for now.

As for me...

Thinking whether to implement a proper scheme for localisation, using sonar maps from now; need to discuss with the others. Plus, flow navigation model is nearly complete, have to test it. Nothing more...

whoa! a lot has been finished in the last three days. we had been facing some hurdles since the previous week regarding, the two most critical ones being:
* UART communication protocol
-could achieve frame transmission from AVR but the opposite didnt seem to work. Also major screw up with the baud rates. this being the only link between the motherboard and the mainboard, was jeopardizing our interfacing plans
* Two wire Interface (TWI) master slave
- couldnt make anything work. and with all the motor control stuff depending on this crucial link, i was kind of tensed. The electronic compass had an option thought (PWM)
over the past few days these hurdles have been buried six feet under :-) now everything works seamlessly. The diagnosis::
*the AVR ATmega16 's internal clock fuse bits were not disabled, so the external crystal was not being used. resulting in wrong baud rates
*wrong serial connector (female instead of male) at AVR end lead to Rx pin mirror image, and that caused all the problem
*TWI, well, we just made our own protocol, although in the line of TWI. this seems to work pretty well now, at 128 fps minimum. thats more than enough for our need. but i have plans to make the hardware TWI though in near future.
* all the sensors ( 4 SONAR + 1 compass) are now functional). mrinal now gets all these information at his end without any frame slip

so now things look pretty promising. besides the trouble shooting of these irritating problems, most of the other small things are also over
tomorrow onward we'l probably start our integration

Current Mood: accomplished
Current Music: coroner - golden cashmere sleeper

These last few days have taken some getting used to. Coding and refining...coding and refining...the endless cycle. Only today did I interface Mrinal's serial handler code and the Corelib library into the Core. There are a few other things that are left to be done. We need to drag and drop ROAMER's obstacle avoidance algorithm into the ExecutionEngine using a Strategy pattern as discussed before. Mrinal's going to write the structure for the sonar data structure, since he has already worked on ROAMER. Other than that, the other data that I'm currently getting is the compass bearing. The update functions for both these sensors are linked to the serial handler using libsigc++, which rocks for this kind of work. Our code meshed seamlessly, and I'm thankful there weren't any headaches in this direction.
OK, installed FLTK on the target Linux machine. The code performs flawlessly (should I've expected differently?). Work on the main loop to be completed within one more day. The ROAMER stage is not too far off, but I'm still a bit worried about the picture from the webcam. We read the reviews of this particular webcam (logitech Webcam Express) and nobody wants to touch it with a bargepole, say it's a waste of money, etc., etc. Hmmmm.... :-(

There are a few other things I'd have liked to say about JD's side of developments, but I'll defer that to him; both of us are in an update war to see who posts first. Sigh....

Current Mood: cheerful

Now that I've actually gotten down to naming my releases, people will have some idea of exactly how jobless I am. Anyway, the COMRADE Preproduction Core is ready. Featuring a decoupled execution engine, the IRIS core (unoptimised) runs at around 3 fps (for rudimentary image processing operations at 320x240).

However, if I remove the boundary checks when accessing the image buffer (I want to remove them later, since we'll always be working with 320x240 and its (sub)multiples. Anyway, after removing the boundary checks, I get 5 fps.

OK, here's the deal. Target for rudimentary image processing: 15 fps. That'll have to be done by (possibly) going into inline assembly for some sections, but it'll have to wait. Currently, my main target is to eliminate the conversion code that actually converts libfg frames to IRIS' frame format. Need a bit more time with that, or get a new library.

Next, the bloody webcam gives me GREEN images! GREEN, like some Matrix effect, and NO, I cannot do histogram equalisation on those images, because the other color components are just not THERE. And libfg's color balance and hue control functions have no noticeable effect. Investigating solutions for now...

OK, guys, I need feedback. I'd like it if someone could actually enumerate all the segments which are working and those which are still under development. Just so that I can start integrating all those components which currently exist as stupid Proxy wrappers. Need to integrate the UART code as well as the structure for all the sensor data...JD and Mrinal just finished it in a night...amazing.

One more thing. I need comments on the performance or IRIS. You people want it faster or it's good as it is, or what...?

Long post: going to sleep, promises to be another hectic day, plumbing the depths of void* pointers...

Current Mood: tired

I'll try to summarise my thoughts:

• The MulticastSignalBuffer class is finished; it exists as an object inside ComradeFrontEnd.
• An execution engine is needed. According to some instructions (these instructions are to be downloaded from the Main Node, so the execution engine will use Sharad and Mrinal's multicast library), it will call routines using iris_vm_ptr.
• To get the frames, the libfg library must be included in ComradeFrontEnd, with the image buffer conversion routine. This is best encapsulated into the AbstractHardware class; very logical because we need not know where the data comes from.
• A buffer for sonar and ADC data must be created and made accessible to JD's microcontroller library. I think this buffer should be incorporated in the AbstractHardware class as well.
• When the execution engine calls the machine vision library, the various parameters must be readable from Mrinal's XML structure.

It still remains to be seen how much of BorgCode can be implemented before the deadline. Maybe not even a small part of it, but just a stopgap for now. But there must be provisions for seamless transition to the BorgCode engine. IRIS Aquarius release is possibly going to be the last release in which IRIS comprises the bulk of the source. As soon as the other headers and libraries are included, we'll have the COMRADE Preproduction Core ready: the CPC Hades Release. Looking forward to it.
Designed a simple CircularBuffer in namespace IrisFoundation for use as the image buffer, sensor data and signal buffer. Now would be a good time to summarise the existing namespaces.

• Comrade::Corelib
• Comrade::IrisFoundation
• Comrade::IrisXT
• Comrade::Iris3D
• Comrade::Osiris
• Comrade::IO
• Comrade::ComradeRuntime

Wrote the barebones ExecutionEngine class. Made some changes to Mrinal's FrameGrabber header, including adding buffer conversion from its own FRAME structure to the IRIS Buffer class. Things left to do:

• Include the microcontroller library. It should be incorporated inside the AbstractHardware class. Should it always keep running in a separate thread (independent update), or use only query-based update?
• Incorporate the Configurator class seamlessly into ComradeFrontEnd; also, find out the exact structure of the configuration tree. Might hardcode the parameters if time is short.
• Add update() functions to the ExecutionEngine for updating image/sensor data buffers.
• Add specific routines for line-following, object detection, including interactive training routine(s).
• Build in the polling framework, and allow options between guided interactive operation and autonomous operation.
• Include ROAMER's obstacle avoidance algorithm by default??

robotics at JPL

Current Mood: excited

well, after the endless component soldering session which lasted 6 hours (12am to 6am), we met again at 4pm for the the critical motor control board testing. we had our fingers crossed and were ready to spend another night debugging any errors that might have crept in

whoooa....everything worked on first trial!!! kudos to mrinal's amazing board design, and a little bit of credit goes to sharad and me for soldering everything perfectly :-)

now we are geared up for the next phase of testing; the AVR code dump, and TWI(two wire interface) testing.

the exciting phase of our project has begun :-)

Current Mood: cheerful

jd_knight, snagappa and I just finished a marathon soldering session. Managed to get three PCBs ready, so we can start testing them tomorrow today.. *Fingers crossed*, hoping they work!

Zzzz...

well, the good news is that i finally finished coding :-), the bad news is, it's untested. no saying how the uC will respond to the master, it might even not respond :-(

the TWI/I2C slave implementation is also finally done. after two rewrites and a bit of tweaking, i'm hoping it doesn't have any bugs. only one way to find out. we should get the micro-controllers and the boards by friday. after that it's going to be testing, more testing, and even more testing. hopefully everything will work without too much hassle.

Current Mood: satisfied

Sheesh, and now there really is much to do.

Deadline 1: 14th April
Deadline 2: First week of May

BTW, finished preliminary optical flow engine design, may test it today. Plus a command line, plus the robot intelligence, plus feature enumeration...these need to be done. Eminently doable :-)

As I write, Sharad's on his way bringing up Linux CD's for installing on EVE's hard drive (kindly donated by JD), Mrinal has just finished his Battlemaster.net session, and JD...is making tea :-o

Small steps, but on the verge of something...maybe?

started 'micro-controller coding' for the dc-motor control boards in earnest for the third time this week. kind of a tedious job, with dozens of #defines. i'm half done with the i2c/twi slave implementation. now i just have to wait for the next big change that comes along...

i just found a really dumb mistake where i was writing to the i/o port instead of the data direction register for that port. i hope there aren't any other mistakes like that, debugging will kill me :-(

disclaimer: i refuse to be held responsible for any silly mistakes sharad nagappa makes in the microcontroller code.

As I speak, I can see ADAM and EVE moving in unison towards me, malignantly pushing my chair, wounding me left and right...help, they're going to get me!! NOOOOOOOOOO....

Finally! The world will see IRIS in all its (notoriously unstable) glory. Click here to check it out. Of course, additional responsibilities ensue but never mind :-)

We bought the 2.4 GHz machine on which IRIS shall run. JD's already planning on cutting up the cabinet to mount the motherboard onto ADAM.
On a smaller note, ported IRIS (the Bleeding Edge Version) to Linux. Works on Windows too, as expected.
Hey, how about a new site design? Spanking new. Sharad and JD have no problem. Will be in tune with the IRIS minisite, should be up by the time you may be reading this. OK, by the way, please do not try to compile the stable or the Bleeding Edge Release of IRIS under Linux gcc. Will put up the updates soon.

And while I've been gone on a vacation, great things have been happening. We have two robots, JD has mentioned it already. Coding the lower levels has started in earnest. The beginning of another hurly-burly stage of development.