complicated math question

[tater1337]

I could test it on the simulator, but I dont think I could come up with a confident test for it.

how does that math work on a picaxe? say I want to do this

compassheading=((compassreading/255)*36)+37-goaldirection

but not

compassheading=(compassreading/(255*36))+37-goaldirection

ok? i thought I read in a post picaxes do the mathe left to right, regardless of the operations involved instead of the standard multiplication, division, addition, subtraction. so by deleteing the parentheisi(?) i'll still get the first equation, right?

if so I can free up a couple lines on the 14M

P.S. the guidance program looks finished, fits in the 14M with 6 bytes to spare, but looks buggy, so need to test, no GPS yet, servos on the way, need to order hall effect compass

 

[hippy]

PICAXE maths is all left to right so there is no operator precedence. Your desired calculation ...

compassheading = ( ( compassreading / 255 ) * 36 ) + 37 - goaldirection

Is strictly a left to right evaluation so you can use ...

compassheading = compassreading / 255 * 36 + 37 - goaldirection

A point to note is that if 'compassreading' is a byte variable ( holding 0 to 255 ), dividing by 255 will give 0 except when 'compassreading' is 255. That may be what you require, or you may be using a word variable so may not be applicable.

 

[womai]

Unless compassheading is too large to begin with (larger than 65535/36 = 1820, which would cause an overflow), the following formula will give much less roundoff error:

compassheading = compassreading * 36 / 255 + 37 - goaldirection

Wolfgang

 

[tater1337]

Unless compassheading is too large to begin with (larger than 65535/36 = 1820, which would cause an overflow), the following formula will give much less roundoff error:

compassheading = compassreading * 36 / 255 + 37 - goaldirection

Wolfgang

heh, yeah it would. was more concerned about order of operations rules tho

original code section was this

readadc 4,compassreading
compassheading=compassreading/255*36
turnhere=37+compassheading-goaldirection

but I might even cut it tighter by geting the result to be either 1 or 2 and use it to address which servo rather than use an if-then statement

 

[BeanieBots]

Read post #2 again.

ReadADC will return a value between 0 and 255

the line compassheading=compassreading/255*36
will only return either 0 or 36. No other numbers are possible and 36 will only happen when compassreading is 255.

 

[tater1337]

Read post #2 again.

ReadADC will return a value between 0 and 255

the line compassheading=compassreading/255*36
will only return either 0 or 36. No other numbers are possible and 36 will only happen when compassreading is 255.

crud thats right, i forgot we cant do decimals.

hmmmmm, maybe i'll toss a 8 level if-then-esleif in there.

here was the plan, use a hall effect compass in a ladder config to give me an analog reading 0-255, which I would dive by 255 to get me a number between zero and one, mulitply that by 360 to get me a compass bearing. I then need to subtract the direction i want to go from the compas reading to know which direction to turn, but since I dont want to mess with negatives or have the number be zero, I add another 360. but I cannot add 360 because I can only go up to 255, so instead of 360 I do 36 (tens of degrees).

I think I need to let this sit for a day in my subconsious and see what solution comes out. cant multilpy first unless I plan to use a whole word(i think i could).........

hey hippy, the whole guidance program fits in a 14M! 252 out of 256. just gotta get parts! and get this one bit finished.

 

[hippy]

You can multiply a byte value by 36 then divide by 255.

If you want to go above 255, you can use a word variable.

You can also go above 255 during calculations.

 

[BeanieBots]

The only reason there are 360 degrees in a circle is so that it is easy to calculate using mental arithmatic.
For any 'real' mathematical calculations it's done in radians.
360 degree circles are for humans only. (that excludes mathematicians)
For micro / robotic use, there are 256 'degrees' in a circle.

Use the convention which works with the tools you have.
DON'T convert to some some other "obscure" number system just because it looks more conventional. (N + 256 = N when using a byte).

As for your sums, read womai's post again.
By swapping the multiply/divide you can have your 36 'degrees' to a circle.
(but I suggest you DON'T do that as described above)

By using a word and ReadADC10, you can have 1024 'degrees' to a circle.
(assuming the compass has that level of resolution).

Keep THINKING in bytes and it will all start to make sense.

 

[hippy]

You might want to revisit the logic of the design as well. While you can get bearing and co-ordinates of where you are from GPS, you only have the co-ordinates of where you want to be. You'll have to calculate the angle of where you are to target and then compare the angles. That sounds like a lot of 'nasty trig' to me and you have 256 bytes of code in total.

Would it not be easier to consider the target as the centre of a + with NW, NE, SW and SE quadrants. You can work out in which quadrant you are in by simple comparison, then assume 45 degrees to target ( ie need to head SE if in NE quadrant ), see in what direction you are heading and adjust to turn towards the direction to centre. You could use more 'quadrants'.

Not perfect but the rocket-on-parachute should zig-zag towards the target then spiral about it while it descends. It's the sort of thing which would be well worth trying in some simulation package or busking through it on paper.

 

[tater1337]

You might want to revisit the logic of the design as well.

agreed hippy, i'm gonna take a day off from the furms to sit and think, I believe you are right.

beanie, you are right too, but i think hippy's cut it down tothe bare bones better. I'm thinking 4 if then statements will fix a lot of math.

time to go out in the big room and mow lawn till the mower breaks again.