Floating Point math question

Forum 2005-2010 (read only) Software Syntax & Programs
1

Hi - this is my first post! I've been working on an automated panorama photo 'bot' and have learned a lot so far, esp with no c++ experience.

The following code snippets from my sketch has me stumped:

// camera parameters
float HFOV = 5.0;     // horizontal field of view
float VFOV = 3.0;     // vertical field of view
int triggerOpt = 2;   // Servo (1) or USB (2) shutter release
float FL = 200.0;
float minFL = 150.0;
float maxFL = 250.0;
float FLM = 7.0;
float minFLM = 4.00;
float maxFLM = 10.00;

void recalcdata ()
{
  panWidth = bottomleftangle [0] - toprightangle [0];
  tiltHeight = toprightangle [1] - bottomleftangle [1];
  HFOV = 2 * atan (18 / FL) * 57.29 ;                  // atan measured in radians (1 rad = 57.27 deg)
  VFOV = HFOV / aspect;
  panshotnumber = (100 * panWidth) / ((100 - valOVL) * HFOV);
  tiltshotnumber = max((100 * tiltHeight ) / ((100 - valOVL) * VFOV) , 1);
}

The routine recalcdata() is called after user input for various parameters (eg FL above). After this the sketch returns to a menu system and displays menu items on an LCD using the standard 44780 library. What I don't understand is that the formula for HFOV above causes a repeatable and specific display glitch in one of the menu items - specifically the byte reference of one particular character position is shifted by a set value and therefore displayed as another character.

If I define FL as an 'int' variable and rewrite the code as

HFOV = 2 * atan (18 / (float)FL) * 57.29

all is ok! I'm guessing that some overflow is occurring in the arduino memory and leading to the display corruption, but don't understand enough of how fp math works and was hoping if someone would be kind enough to explain why this happens!

Thanks!
Gadget

2

What value does atan(18/FL) return, when FL is a float? If it ever returns 0, you have a problem.

If it returns 0, then HFOV is 0. HFOV is then used in the next line, in the denominitor, and you have a divide by 0.

If HFOV is ever 0, then VFOV is 0, too. VFOV is used in the denominator in the next line, resulting in another divide by 0.

3

FL has a default value of 200 as defined - the menu system only allows for a variation of +/- 50 (based on the defined max / min values).

The atan function therefore always returns a positive result and therefore HFOV is also always positive (or rather non-infinite :)).

What's really weird is that the 'glitch' only affects one particular menu display item and always at the same character position, regardless of whether I cycle through the menu without making any inputs. Hence could it be that the 'double float' (if there is such a concept?) in the expression creates a memory overlap issue?

4

We would really need to see more of your code to understand where the memory overflow, if that is the issue, was occurring. Particularly, it would be nice to see the declarations of the angle arrays.

But, the point of my question was to get you to insert some Serial.print statements, and maybe some intermediate variables, to see what the input to atan is, and what the output is.

What does 18/FL return? Is it an int, because the 18 is an int, or is it a float, because FL is a float? 18/200, as an int is 0. 18/200.0 is ?

What does the value 18 represent?

therefore HFOV is also always positive (or rather non-infinite

Non-infinite or non-negative?

5

18 is one of the dimensions (in mm, I guess) of the image sensor, IIRC

Would be nice to make that clear in a nice, fitting name,

6

Thanks for the replies. I was busy on other things in the interim although the project sketch is now complete and appears to be working ;D .

PaulS, thanks for taking the time to help. I tried printing out 18/FL to the terminal but only got 0 when the value should be 0.09 (even though I set the number of decimal places to 4), using the default FL value of 200 (FL globally declared as floating).

However atan(18/FL) printed as 0.09 (as it should be with 2 decimal places). Also HFOV printed as it should (being 10.28) using FL = 200. So I guess that 18/FL must return a floating point number internally?
HFOV can never return a negative or indeterminate result given the limits imposed.

All angle arrays are declared as integers.

The actual formula is Field of Vision = 2 x atan (horizontal frame size / 2 * focal length). As the size of a standard 35mm frame is 36 x 24mm this gives the value of 36/2 = 18 in the formula. (AWOL - you're right - I kind of got lazy here and used 18 given it was never going to change!).

As an aside, as a 35mm frame has an aspect ratio of 3/2 this is used to then determine the vertical field of vision.

I'd be happy to post the project code if you would like to see it (it uses the menu system from the nuelectronics lcd shield. It just happens to be very long (and probably more convoluted than it should be!). Most of the sketch is taken up by the menu and display routines.

As I said previously the problem appears to have been sorted via a simple change in the way which FL is declared and subsequently handled in the formula, although I have no idea why.

Regards