A bearing on direction

A bunch of changes over the weekend.

Got the red level parameter working - added command line commands to set and read it. Also patched it into all the commands that require a red level - so you can specify it (and it will save it) or leave it off.

Fixed the C++ arctan routine. There was an error for angle >45 degrees which the unit tests didn't pick up. I had actually implemented the unit tests in the Python version and ported them to C++. But unit tests are only as good as you are to spot the different cases, I guess.

However, above this I primarily got the bearing working over the weekend (displaying this real time is cool) and used this to rotate the plan view. This is the big step forward.

That said, I did come across three problems:

• Picture was 'faint' when running and required a low red level, resulting more noise that I expected ... what I don't understand is that when I downloaded the picture to the Red Extract Mac application, it seemed fine...
  
• Horizontal lines seem to get rotated wrongly - sort of at 45 degrees. Vertical lines get rotated just fine - and point directly 'north'.
  
• When pointing at 45 degrees it sometimes makes corners into a single line, effectively straightening out the corner.
  

The first one is the one I need to work on the most. Two possibilities are it's doing red>blue rather than red>green after first image (for some reason) or the picture download is reset the camera - and hence the auto white balance or automatic gain. I'm not sure auto white balance is such a good thing on a red/white/black coloured image, actually. Of course, it might be something else?

The second item needs looking at. I can probably cope with it if I understand why it's happening - although some of the rotation looked pretty weird. Probably a bug though :-)

The third item can wait until we have more working.

Oh, I also got an overhead light for the maze board as well, to give better, more consistent lighting - at least while I'm getting it up and running.

Next up, once these are fixed are: the robot position measurement/calculation, local wall detect and then onto moving in a straight line...

Finished Parameter Update

Last night didn't do much - just finished off the parameter update for the non-volatile x-offset and camera angle.

Going to add red level to the parameters tonight, program the code into the robot and see if the new 3D code works on the maze. Perhaps if Alan is about I can show him the RealBasic program that displays the robot results graphically. We might also discuss the arctan (need to talk to Stu about this - he helped co-write an article on it) and the Red Extract results.

Arctan & Port

Hacked together a bit of Python to calculate an arctan table. Requires a bit of code to avoid using more than +/-45 degrees. The plan is that Alan and I will test this code in Python before moving it to C++. This is for the bearing calculation. We wouldn't have needed the actual angle for steering alone but we also need to rotate the plan view.

Also moved revised 3D calculations from the Red Extract test app to the robot code and got it compiling. Really need to tidy up the code in that area at some point - it's a real mess, but that prettification can wait till later when the robot does something. Currently I'm in the process of adding the camera angle and x-offset as parameters in the EEPROM so they can be modified without recompilation.

Integer Works!

Quick update .... bug was integer maths problem scaling by 1000 - a simple error in a constant. So it's ready for the transfer across to embedded land. Must send Alan a RedExtract picture to look at.

Also must remember to book everything in both projects into Subversion tomorrow before I do anything.

Of Time and Integers

Hi,

Tonight two things.

Importer time/date
I've had a problem for a while which looked like the Python datetime reporting daylight savings time/summer time for all the LWC timestamps. I thought this was unlikely, but then again the other options looked more unlikely. I tried creating an UTC tzinfo class - but it didn't help. Today I created a new function from scratch to calculate dates from a reference by hand and had to write some unit tests (been using doctest ... very good and quick) - something I was trying to avoid when I used datetime (i.e. thinking). Well, I realised (once my routine was working) I could have used these unit tests to determine how the original actually worked. DOH! Oh well. Anyway, that just leaves LWC and the operating system itself. I'm not sure I'm any better off than an unexpected operation in Python. Email to Stu sent - see what he says... (probably: look in 'this' LWC source file - but we don't do anything ourselves... I say this because I'm pretty sure I looked in the relevant source files a couple of months ago and I'm not sure it does anything apart from call the OS.)

Next up in the importer: Check thousands of conversions by eye. Oh the joy.

MouseRobot
Finished checking over the integer trig. version of the code. I was thinking all the time: 'I wonder how well the ARM7 would run single precision float'. Not sure it would be quicker to code now (after spending the time on the integer version) - but if I have scaling problems, I'm really going to take a look rather than hack the integer routines. 3 significant figures hopefully will be good enough through all the calculations. Now time to run it in the RedExtract test program before moving it to the actual embedded code to check the results. Does it work? Of course it doesn't. Oh well, debug mode, I guess.

Integer vs Floating point

A long time ago, I used to program fixed-point trigonometry maths for 3D engines using integer operations. Over the last few years, with good floating point on all the platforms I've been programming games with, why wouldn't you use float and double?

Recently I've been doing a fixed-point trig for the ARM7 build on the robot. And I must say, it's a big pain - especially with looking out for overflow in complex expressions. Almost makes make wonder whether these set-up functions couldn't use floating point maths.

Game Sales

Stu sent me a link to an interest post from Jeff Vogel of Spiderweb Software detailing how many copies of one of their games they sold and, importantly, how much it cost to develop.

http://jeff-vogel.blogspot.com/2009/03/so-heres-how-many-games-i-sell.html

There are very few good numbers for shareware, indie development or full corporate sales. The more the realistic information, the better, in my humble opinion.

The other 'recent' numbers I know about are Pangea Software on the iphone and Braid development on the xbox360.

There are other 'how many they sold' articles - but unless you know how much they really cost to development, any numbers are meaningless in terms of return on investment.