Calculating Angle to fire at

[seanwitte]

Why so complicated? Build your shooter and iterate through the ranges, keeping track of the shooter launch angle and camera tilt servo position. Then all you have to do is look up the value for the shooter angle based on the camera tilt servo and forget about the range. You can use a joystick button to add a fixed offset to adjust in realtime if something changes on the field and it starts missing.

When I tested the camera code I could only get about 20' away before the trackable pixel area becomes too small. At 6" increments your lookup table is only 40 entries long.

[KenWittlief]

I agree with Sean. With so many variables in the system the only sane way to approach this is by testing your shooter, and averaging the results for each angle or distance or launch velocity, then using a look up table for each distance (or angle)

and if possible, only allow your launcher to vary one setting (angle or launch velocity).

Rick had a good point. In the real world military pilots let the computer do all their magic, they pull the trigger, then they use a joystick to walk the rounds into the target.

Even an A10 warthog with its computer controlled targeting system cannot hit a target 1 mile away with the first round (bullet).

[varcsscotty]

it's not the only way trust me....

[X-Istence]

While I agree that a table lookup would be a lot easier, why not go all out this year, and use the CPU that was given to you, and calculate on the fly. I know that is what my team is doing. While a hash table would be fast, it would be less accurate, and we are personally looking for going for the perfect bullseye at least 60% of the time.

[KenWittlief]

Originally Posted by X-Istence

While I agree that a table lookup would be a lot easier, why not go all out this year, and use the CPU that was given to you, and calculate on the fly. I know that is what my team is doing. While a hash table would be fast, it would be less accurate, and we are personally looking for going for the perfect bullseye at least 60% of the time.

the reason for using a lookup table is something they don't tell you in college. The real world in not linear. There IS no equation for the trajectory of a foam ball through the air for different angles, launch velocities or distances.

You can come up with equations that approximate what the foam ball will do when you launch it from your robot, or you can test fire the mechanism several times, record the results, and know exactly what it will do as each variable in your system is changed.

No matter what equation you use, your going to have to test fire your launcher to get its actual parameters, so you have to go through the same procedure anyway.

but once you test fire your launcher over its range of settings, and measure the results, you now HAVE the answers to the equations you need to write. At that point why calculate the answers each time you fire the launcher? you already measured the results during testing.

besides, a lookup table in SW takes 2 or 3 simple instructions to execute. You add a variable to the table start address, and read the answer from that memory location.

Trig functions on a microprocessor can take hundreds of instruction cycles to calculate.

"everything should be as simple as possible, but not simpler" -Einstein

[Salik Syed]

I think we may also end up using the same method... collecting real life data.
Calculating it is less accurate due all the real world factors that are out of control and too hard or random to factor in(friction, spin etc.)

[X-Istence]

Originally Posted by KenWittlief

the reason for using a lookup table is something they don't tell you in college. The real world in not linear. There IS no equation for the trajectory of a foam ball through the air for different angles, launch velocities or distances.

You can come up with equations that approximate what the foam ball will do when you launch it from your robot, or you can test fire the mechanism several times, record the results, and know exactly what it will do as each variable in your system is changed.

No matter what equation you use, your going to have to test fire your launcher to get its actual parameters, so you have to go through the same procedure anyway.

but once you test fire your launcher over its range of settings, and measure the results, you now HAVE the answers to the equations you need to write. At that point why calculate the answers each time you fire the launcher? you already measured the results during testing.

besides, a lookup table in SW takes 2 or 3 simple instructions to execute. You add a variable to the table start address, and read the answer from that memory location.

Trig functions on a microprocessor can take hundreds of instruction cycles to calculate.

"everything should be as simple as possible, but not simpler" -Einstein

Ah, I knew I was missing something. I see why a lookup table would make more sense.

[seanwitte]

Originally Posted by X-Istence

While I agree that a table lookup would be a lot easier, why not go all out this year, and use the CPU that was given to you, and calculate on the fly. I know that is what my team is doing. While a hash table would be fast, it would be less accurate, and we are personally looking for going for the perfect bullseye at least 60% of the time.

Theres nothing wrong with that approach, but time is a finite resource and it is not the hardest problem here. It seems to me there are two very difficult problems involved:

1) Build a contraption that consistently shoots the balls at roughly the same speed (and hopefully direction!)

2) Build a gimbal mount that can be quickly and accurately positioned to control the launch angle for the gizmo in part 1.

I think part 2 will be the deal breaker for most teams. Moving an appendage is one thing, but this requires tight tolerances to make it work.

[David Brinza]

Originally Posted by seanwitte

Theres nothing wrong with that approach, but time is a finite resource and it is not the hardest problem here. It seems to me there are two very difficult problems involved:

1) Build a contraption that consistently shoots the balls at roughly the same speed (and hopefully direction!)

2) Build a gimbal mount that can be quickly and accurately positioned to control the launch angle for the gizmo in part 1.

I think part 2 will be the deal breaker for most teams. Moving an appendage is one thing, but this requires tight tolerances to make it work.

The KISS rule probably applies here (as in most things in life).

You need to understand the relative complexity of items #1 (consistent speed) vs. #2 (agile and accurate gimbal mechanism) and factor in the relative importance of 1 vs. 2. It seems to me that unless you plan to alter the launch angle based on the launch velocity on the current shot, #2 is not very important. If you shoot the ball at fixed angle and consistent speed, you should be able to deliver the ball in the proper height over a rather large range from the goal. I think that's the key in this game.

Hint: play around with the Excel spreadsheet I posted earlier in this thread, now attached below with a minor correction. I now divide by 8 in the drag factor parameter instead of multiplying by 0.128 (obviously I meant to multiply 0.125 in the original version...2% error - my bad!)

[Tatsu]

if anyone uses mathematica, here's a notebook to generate ballistic lookup tables..

initial values are declared at the top, target height is deltah (3.5 ft or whatever) * ft-> meter conversion.

all values should be done in metric.. at the end, just display the contents (or export to CSV) and load em onto the bot.

I'm sure a few of you'll figgure out some more inventive uses..

<-- currently working on a 3-dimentional version.

No, I'm not a programmer.

[Mark Pettit]

Another variable to your equations might be the "plug" that these balls have on them. The plug must be a necessary part of the manufacturing process. It really makes them wobble if any spin is introduced.

[BotLobsta]

I added the equation that Matt came up with into my firing calculations to have a basic trajectory to test with, and I got the following error:
Error - section 'MATH_DATA' can not fit the section. Section 'MATH_DATA' length=0x00000014

I looked in the linker script and could not find that section, nor could I find mention of it anywhere else in any documentation. Any help?

[Tatsu]

those of you intending to use lookup tables, here's a lookup table for you to play around with..

its around 108kb, but you can trim it by deleting the first portion (the ball wont even go in)

first column, theta
second column {distance-to-goal,total-distance-traveled-till-ground,risidual error}

risidual error shouldn't matter unless you're seriously nitpicky, it'll give you a relative idea of how much error there is for each theta..

[Korbin]

Originally Posted by seanwitte

When I tested the camera code I could only get about 20' away before the trackable pixel area becomes too small. At 6" increments your lookup table is only 40 entries long.

was this tested using the four bulbs that came in the kit, or with all eight that will be used in competition?

[Andrew Blair]

There are eight cathode included in the KOP. Two per box. But I also wonder if only four were used; we were considering it, though we used eight, and with eight, it is pretty bright. But we haven't tested yet.