[Dave Flowerday]

Originally Posted by steven114

but it seems to me that replacing variables which do in fact hold floating point values with integers just because it saves you a few bytes of space is worth it.

I think you're missing a key point here: the microprocessor inside the RC does not support floating point operations in hardware. Why is this a big deal? Because now, every time you add two floating point numbers (or divide, or do basically anything with them), the compiler has to generate quite a few extra lines of assembly code to do that (in some cases, several dozen lines of assembly). So, in essence, each time you use a floating point operation, you're consuming an order of magnitude more program space than if you had used an integer (nearly all integer operations are a single assembly instruction). This also translates to taking much longer to execute. All in all we're potentially talking about hundreds or maybe even thousands of extra bytes, not just a handful.

Generally, if it works in testing, it will work anywhere

Man, I really do wish that was the case... Why do you think so many professional software programs out there are still buggy? The problem with software is that it is extremely hard to create tests that exercise every bit of a program in every possible running scenario and to test all the different paths through the code that can be taken.

you're not likely to save enough to do anything significant with a few extra bytes here and there

Our control system was complicated enough last year that we filled up the program space completely. We were able to work with it and take care of it, of course. But we were careful from day 1 to employ good software practices (we're a team heavily populated with software engineers so it comes naturally). The trouble is that if you take the attitude of "hey, as long as it isn't causing any trouble it's fine" you may find yourself with 5 minutes before the match that could mean winning or losing the tournament only to find out that the tweak you need to make to your autonomous code won't fit because you're out of space! If you ever find yourself in that situation then I guarantee that you'll wish you had been more careful about using resources wisely.

Also, if you ever end up developing embedded software for a living, you'll find that companies generally want to put the smallest, cheapest microprocessor inside something that they can get away with. If your company is going to ship 5 million of the newest, hottest gizmo to all the teenagers in the country, and you tell them that you need to spend an extra $1 or $2 on a faster processor, then that's $5 million extra cost to produce the product that the company will either need to pass on to the customer (and hope the competition doesn't do it for less) or subtract from the profits. In that case, writing efficient code will be seen as very important.

Originally Posted by miketwalker

Dave, do you know any other ways to work with the decimal calculations in these sensor calculations so that you run the least risk of having problems meanwhile still keeping the accuracy neccessary?

I know you're talking to the other Dave, but..

One trick that we use frequently is to take a 16-bit number and treat the lower 8 bits as a fractional portion. That way you can stick with simple integer math operations but still obtain higher accuracy. We've done this with all of our distance calculations from wheel encoders, angle calculations from the gyro, PID controls, etc. There are always tradeoffs where using floats is justified and a decent idea. I think Dave was trying to make the point that (like any compromise) you just need to be smart about it and not make the decision without taking some time to consider the consequences.