Micromouse contest - MINOS 08 - report 3

At the end of the first day we had a really good meal at a local Italian restaurant and I think everyone got on really well and enjoyed themselves.

On the second day, the main thing (apart from a very nice breakfast) was the competition. This was pretty informal and there was a good atmosphere. It was timed and scored for each run.

Adrian divided the competition into heats and finals. The slowest in the qualifying heats would go first in the finals. These themselves were divided into wall follower and maze solver races. Even the mice that didn't finish were given a chance to run in the final. Perhaps there was over dozen mice competing with a fair number of different designs.

The wall followers were both contact and non-contact in one race - there probably weren't enough mice to split the competition into three races.

Quite a lot of the mice suffered very badly due to wall detection problems. They used a standard plastic wall set and it's the third year these walls have been used and some people hadn't altered their mice sensors - so something was up. I did wonder whether the walls had aged somehow and become less reflective of IR. They looked OK in visible light, of course.

Between races I got a chance to do some more on the vision processing code. A few things to sort out yet - but I'm getting further bit by bit. Of course seeing all of those mice compete really made me want to run our mouse. Still, without the vision processing the only place it will go is straight into a wall!

The event finished earlier than scheduled at somewhere between noon and 1pm. The only bad thing about this was a four hour wait at Heathrow, which is probably one of the most boring, soul-destroying places on the planet. At least I had Alan to talk to, my phone (to ring Claire) and my laptop. Things could have been SO much worst!

Micromouse contest - MINOS 08 - report 2

Today was mostly talks and presentations. There were a couple of 'practice' sessions where we took the opportunity to take some shots of a full size maze using the robots camera for off-line processing. A full maze is 16x16 cells and measures 2.88m square - so it's a bit big for my house. (We have a 5x5 practice maze).

There were talks on accelerometers, intelligent mice, chassis design, another paper on machine vision (but done very differently from ours), basic mouse design and many other interesting topics with much food for thought thrown in. There seems to be a lot of details to building a really good mouse - something that isn't apparent on the surface.

My talk went well (Alan tells me) and we got some good ideas including some names of some useful image processing algorithms and a later talk (by Tony Wilcox) reminded us that we could use programmable logic plus fast memory to remove, effectively, the CMUcam3 from our design (which we use for processing and the FIFO). Strangely we had talked about that and dropped the idea in favour of the a FIFO/second micro. I guess, although a lot of programmable logic is in-circuit programmable, I was more comfortable (and thought I could work quicker) with standard code. Today's presentation - and our vision work over the last few weeks - might have changed my mind.

However, we are not going to do that immediately - the algorithms are the same whether we have a processor doing them or programmable logic. However it would give us a solution for any slow processing speed we come up against - since we could do the capture AND at least the first two image processing algorithms (bitwise filter and red extract) in hardware on the programmable logic. It might even mean we had power to process a higher resolution camera.

Hopefully more tomorrow.

Micromouse conference - Minos 08 - report 1

So Alan and I are on our way to this tiny conference. Got up at 4:50 (yawn) to get the significantly cheaper flight. The plane was overbooked but we were eventually able to get on anyway in the end (last two people on - it was close enough that they talked to us about
bumping us to the next flight).

We'd hoped to have our mouse running, but it's not quite there. We have done most of the vision processing as a Cocoa application. This allows us to process pictures taken by the robot and process them into, ultimately, wall/robot positional data.

At the moment the Cocoa application does everything except properly convert the coordinates to the world domain. I was working on a couple of constants we need to insert and haven't had a chance to try them on the program over the last few nights.

I've volunteered do a presentation at the conference to show people what we've been doing. We spent Wednesday and Thursday writing this presentation and I spent last night packing (mostly). However, I have to be careful not to focus overly on the presentation slides and
actually show people the program - which is what I really want to present.

After the conference we need to finish the world coordinate conversion and then do a port to embedded robot code of the vision processing algorithms. The Cocoa app was definitely not written for execution speed or a small RAM footprint, but it shouldn't take very long to
convert. We can then see whether it's got any major problems like execution speed, poor positional accuracy, motion blur, etc..

I'm hoping that I might get a chance to run the application during the conference with those constants inserted and see whether it's complete rubbish or not.

Hopefully more later!

The amazing blog mail gateway

So here I am posting to blogger via the email gateway. I know it's not exactly state of the art technology but I'm sort of hoping it makes posting from an iPhone easier. Certainly the iPhone email client is a lot faster that the blogger web client on the iPhone.

I wonder whether this will mean I post more often? Doubtful :-)

UPDATE: I originally sent this post to the wrong email address, so it's not foolproof :-( Additionally no copy and paste means re-typing is the only option when using just the iPhone. Perhaps any post longer than a few words needs to be typed in Notes and then emailed from there - that's what I did for this re-post.

Also you can email pictures from the iPhone - so I'll have to try that.

Red Extract - Cocoa

So I've been working on a program started in July last year (2007)* which wraps a terminal program I wrote to process image data for the robot. The encapsulation basically puts a nice (cocoa) GUI front end on it so that I can twiddle parameters dynamically. Like all things when you are not an absolute expert, some things take a long time - in my case it was 8 hours to put a raw bitmap on the screen with NSImage. The final solution? About 4 lines of code!

Anyhow, the real useful stuff starts now - trying various algorithms to do the image processing. Should be fun if a bit of an unknown.

By the way, this post was typed on my iPhone directly onto blogger (edit HTML because compose doesn't appear to work). Feels very sluggish and the phone is warm so I guess I might try sending in a blog entry by email.

P.S. The gap was because as well as having other commitments we also changed the hardware architecture to include two processors and a video fifo.

Copy of email about Robot Vision

I've got the images properly coming out, in their proper colours, now. And as we suspected, I've had no problems with getting images - so it was the fact I hadn't set up the ports before initializing the camera. I've attached an image for your interest.

(it's a bit yellow because of the lighting)

As for the colour order, well, I was trying to understand why it wasn't BGRG as per the manual, but GRGB...

Additionally I noticed we are getting a yellow last vertical pixel row (when looking at white). Magnify attached if you want to see. I suspected that this had something to do with the fact that the colour order (RGB order) wasn't what thought it should be, i.e. we were a sub-pixel out. This bug was complicated by the fact that my bitmap (BMP) image converter had a minor buggette in it (BMP format stores the pixels as BGR for Intel/little endian reasons) .... .

The text below the dashed line explains what I saw when I looked at the raw HEX file and what I conclude from this.

After reading the text below you might think 'why does this matter since the image looks ok?'. Well, one thing is that since we are proposing to do colour detect ... if we end up needing every single bit of resolution we need to understand what we are actually getting in terms of colour pixel position. That Bayer filter is bad enough without having shifted colour pixels we don't understand...

If resolution turns out not to be a problem then it's probably irrelevant.


--------------

Suspected hardware bug ...
When CCIR656 mode is off (CCIR601 mode) we get the last byte of the line (1280 wide line) as 0x10 (i.e. black level)
When CCIR656 mode is on we get the last byte of the line as 0xff

CCIR656 mode puts a 4 byte start header and end header which is FF 00 00 xx although these don't appear in the fifo data (normally) since they are outside of the HREF window.

Therefore it looks like we are dropping the first pixel written to the FIFO.

We also see this "feature" in their code, where they read green first (GRGB) even though the data sheet clearly says BGRG ... (We have to do this as well)

I *suspect* this has something to do with the HREF/NAND gate hack (rather than, say, the pixel clock which appears to be set as rising both in the FIFO and the camera for data valid).

However, since it really only effects the last pixel it probably doesn't effect us as long as we keep in mind that the pixel positions are moved for blue pixels, and I'm not going to spend any more time on this.


Regards,
Rob

Multi-threading

Stu has been doing lots of threading recently and seems to be having lots of fun. I makes me want to incorporate threading in the programs I'm working on at the moment!

It appears that there is one big advantage and one big disadvantage:

Advantage: you can avoid explicit state machines - sometimes essential with other peoples code you have no control of (e.g. OS calls, library calls, etc that just lock until completed). This simplifies your code immensely. It can make a complex program several simple programs.

Disadvantage: Mistakes in the threading design or programming are horrible to debug and can cause almost random behaviour that can be impossible to debug and track down.


Comments?

Random read if you have spare 5 minutes

http://math.hws.edu/javanotes/c8/s1.html#robustness.1.1

You know, I thought that access to vectors via [] would be fine in, unchecked, in programs you understand totally yourself. However, a recent medium complexity C++ program* (a text converter in this case) showed that me that this is not the case. It was crashing on the gcc build. I compiled it with VS2005.Net (to debug) and luckily the debug version has vector [] out-of-range accesses trapped (thanks Microsoft! I don't say that very often!). It immediately showed me the illegal access!

It's trivial to subclass vector to make Vec (it's in Stroustrup tC++PL) where [] access cause at() to run - at() is the same as [] but checked. I hadn't done it because I thought there was no way I was going to fall foul of it in such 'simple' programs that I had written myself.

(This isn't meant to be a lecture by the way!)

Which goes to show - perhaps all array access should be checked, all strings/containers should be self expanding (i.e. avoid buffer overflows) and memory should be garbage collected, etc. and Java people really had it right - in all cases, even for games, embedded, real-time, and all the rest.(*2)

I'm not sure how far Obj-C goes with this regard ... I've asked Stu.

Python has these things. C++ has a sort of poor half way house from C (if I'm being honest) even if it's blazingly fast(*3). And I'm not suggesting we all convert to Java - just that I think these things are things that should apply to all programming languages regardless - at least as a switchable option. Let's face it - a lot of the ancient BASICs had checked limits on array access.

Some new, big programs that I'm involved in worry me - manually locking with threads, manual memory allocation, etc. All bugs that won't necessarily get caught to make nowhere near a CORRECT and ROBUST program (let alone proving those things). Are we building the same faults in that our current systems suffer with - great from the outside but a extension and maintenance nightmare in 10 years time?

Also - why does it appear that Java is so much slower than C++ on the applications we run at the moment? It can't just be the limit checks outlined above. And surely the JIT compilers are fast? Is it the type of applications that are written with it - i.e. network heavy and dependant on the response time of remote servers?


BFN
Rob

* NOTE1: The reason it's C++ (when all the other programs I was writing to do text processing are Python) is because of the number of cross-references for the several hundred files I have to parse. This is even though I have duplicate data in both vector and maps to make access hyper fast and it still takes many minutes to run over the code-set I'm processing

*NOTE2: I'm aware of things like programming-by-contract programming, defensive programming, leaving your assertions in production code, etc.

*NOTE3: I won't even mention that it appears that only 50% of C++ compilers complain about uninitialised variables being used... Grrrr...

Shaping what we do

What a huge gap! I didn't realise I hadn't posted for this long.

An interesting realisation I had last week (that is probably obvious to many people) is that everything we do is shaped by our limitations as humans - that includes physical and mental abilities.

I want to talk about lifetimes - but I'll digress for a bit.

One of the things I mentioned several times last year (maybe even on this blog) was that one thing that bothered me is people talking about the 'unlimited abilities' of the mind. I have no issue with 'unlimited possibilities' (or at least a good approximation) but I see no evidence anywhere of unlimited abilities. I'm not talking about peoples often under-appreciated ability (by themselves or others) to learn any skill. I'm talking about things like: you can remember an unlimited amount of information or, and this is my favourite gripe, unlimited multitasking abilities.

One example: I was at a workshop to do with several technologies and some engineers were discussing that the mind had unlimited multitasking ability. Someone cited the example
of what one of their children had learnt to do simultaneously; chat on instant messaging with friends, chat on the phone, a couple of other things and do their homework. Well, maybe, but probably not. But there are people (scientists actually) who learn about what you can and can't do at the same - it was reported in New Scientist. And their findings show that the human brain is anything but unlimited in terms of multitasking ability.

Another example: talking on a mobile in your hand and driving a car physically reduces your ability to drive - cause one hand is tied up. But its been shown talking on the phone reduces your ability to drive and this is linked to your limited multitasking ability.

Back to lifetimes.

I seems that the things that we do as the human race are limited by the length of our life. For instant, and this is the example that sprang to mind last week, getting to moon or even another planet in our solar system is possible. But getting to another star, whilst difficult from a resource point of view, is probably limited by the amount of time not just to engineer a solution - but the mission time. Probably it would take many decades even at the fastest speed we could achieve. I think this is the limiting factor.

The same goes for people doing research; ever wondered why a very futuristic technology is only 10-15 years away? Funding. But why is funding limited to this time-scale? Because people want to see results in their working lifetime. I appreciate you also have things like inflation and gains on other investments completing against you.

Of course, I'm attributing the cause in all cases to be a single thing. But I bet it has a much larger effect than people appreciate - and are may even not be aware of - because we live in this time span and therefore our thoughts are bounded by it without our conscious realisation. It's also depressing to think that you are going to die before all the good stuff happens :-)

So what's all this got to do with a programming blog?

Well, if we ever get an artificial intelligence with replaceable body parts their life might extend to hundreds of years (assuming they don't have fatal accidents). What will their take on be a 500 year trip to the stars? Maybe a lot different from ours.

And assuming war doesn't break out between humans and the AI then what will they make of our shorted lived race?

Version Control

As has been mentioned elsewhere, I'm currently moving our internal version control from cvs to subversion.

Thing is, that I do so little work on the system (usually just backups) between installations (which are very rare), I have to learn how the old system works before I put the new one in place!

Oh well, perhaps tell you more later on.