Imagine a rectangle

[horkesley]

Hi,

Imagine a rectangle, size not important, but in the order of 30,40 metres.

From each corner I want to create an arc numerically (not on a screen), a list of x,y coordinates forming an arc.

I can use x=r*cos theta and y=r*sin theta to produce a list of x,y data, where r=radius.

How can I place each arc in the corner of the rectangle?

Any ideas would be of interest.

Regards,
_________________
Horkesley Electronics Limited

[Douglas Kennedy]

You didn't state explicitly what you are looking to do but this might be of help.
Well x=rcos theta y=r sin theta has the assumption of a center at 0,0 in Cartesian coordinates. Now what you need to decide is where you need the center for your arc to accomplish your goal. This choice of the center makes for a transform
x'=dx+rcos theta y'=dy+rsin theta. where the new center is (dx,dy). Often if you set the left bottom corner of your rectangle to have (0,0) as its coordinates and align the sides with the axis the calculation is simplified.
Now I hope you aren't planning on a crop circle hoax. Crop circles are involute curves formed by having a string fixed in someway (like wrapped around a fixed barrel) and tracing a curve by keeping it taut as it unwinds. If ET is making these circles involute must be the only curve they know of.

[horkesley]

Hi,

Within the rectangle a 'mobile' knows it distance from each corner.

I can cast an arc from each corner and look for an overlap to establish the position of the mobile within the rectangle.

Three or four overlaps will create an area where the mobile is.

This is an RF system and much checking is required due to multipath etc.

A lot of the work is completed but generating arcs and looking for a 'window' is yet to be completed.

Regards,
_________________
Horkesley Electronics Limited

[Douglas Kennedy]

The solution involves an area in which the precise position of your mobile is located. The area is shaped by the arcs subtending from the corners. The issue will be notating this area efficiently using the PIC. If the arcs overlap thats one thing if they don't overlap its another, if some do and others don't its another also.You could pixelate the rectangle and notate the area as the list of pixels within the area. I'd look at a finite difference approach. Look at the circle algorithms for drawing a circle on an LCD screen. Using Breshenhams circle algorithm centered on one corner select in all the pixels within the arc and give them an attribute of one. Move to the next corner all pixels within this arc and also within the first get an attribute of two otherwise an attribute of one. Move to the next corner same thing with attribute of one for no overlaps two for two overlaps 3 for three overlaps. On to the last corner. Think of it as coloring an lcd screen where the color deepens depending on the overlaps. Pixels with a count of 4 are your best position values 3 next best. If you could estimate the error on your radius then I'd use the error as a brush width and deepen the color of the overlapping brush strokes. The nice thing about finite differences is that you won't need the cos sine float notation at all everything will be integer arithmetic with few multiplications so it will be fast and give every chance of keeping up with rapid position changes of your mobile should they occur. I know you object to a screen approach but the sine and cosine functions are infinitely smooth mathematically this means it is impossible to represent them in a digital device without in effect destroying the smoothness by truncating them at a finite number of bits of storage. This is no different than pixelating your rectangle to accommodate storage. Suppose you pixelate to sq meters then you rectangle is 30 by 40 1200 pixels. At 1 sq cm you have 12 million so your choice of precision will be critical to your storage notation. The notation could be the start and end points and the radius of each arc ( 3 numbers) with the notation fed into a difference routine that would compute the pixel space. The space is stored as 4 sets of 3 numbers and computed when needed rather than kept as a list of pixels.

[horkesley]

Hi Douglas

Thanks for your comments.

Your ideas are more or less the way I am thinking. I visualized a spead sheet sort of approach with the cells having attributes.

The sells not only have the 1,2,3 attributes that you suggest to indicate arcs over lapping, but various other details are also attached to cells.

In terms of resolution I only need to achieve about 100cm accuracy in the cell.

Thanks for your comments.
_________________
Horkesley Electronics Limited

[horkesley]

Hi,

I have been trying to use Bresenham algorithim to plot an arc.

I can't control the increment size as the radius figure controls the number of calculations.

I want to calculate an x and y coordinate for every degree of arc, for 90 degrees with a max radius of 50 m, this should give the resolution I require.

I have searched the web for ides but have not been able to resolve this.

Any ideas anyone?
_________________
Horkesley Electronics Limited

[Douglas Kennedy]

The radius issue is wrapped up in the granularity you choose for your rectangle. Think of this as pixelating the rectangle. For long 16bit numbers your radius pixels can be in the 10k range. Your worst case would be a radius equal to the diagonal of the rectangle. Now the difference mathematics for a circle takes into account the 8 fold symmetry so it stays in the N to NE sector and proceeds with south and southeast steps. The code below was modified by me to allow for an aspect ratio . LCD pixels aren't always square Ex 5x7 hence the aspect ration. The pixelation below was 240 so a long int was needed since any small multiplication would lead to wrap around if 8 bits were used.