Wicked Air Sportz: Turbo Rev

[manike]

Originally posted by hitech
Since it can't store anything permanently, and it clears the tables after paint stops flowing the best it can do is adjust to a single string of shots. Artificial intelligence software? Really?

Yes and apparently it takes at least 16 shots before it works out the table so if you fire less than 16 shots in a burst it won't be able to do it's 'thang'.

And it stops using the ball data after 30 shots... so if you fire a longer string it is no longer 'adapting' to the balls dropping.

So to summarise, it won't be more than an agitator if you shoot less than 16 balls. (What happens at the start of an 18bps burst then....) and it won't be more than an agitator if you fire a burst of over 30 balls...

So if you want to shoot fast besure to count and make sure you do at least 17 balls (the last one will be 'extra fast' ) and no more than 30 or you might chop them...



manike

p.s. Still waiting for the 18bps video of a turbo rev on a non ace'd gun...

[cphilip]

Originally posted by manike
I'm still waiting to see any theory of yours that isn't absolute codswallop.

manike

Ummmmmmm....how the heck am I supposed to Moderate that? I have no idea what that means!

grumble grumble grumble...

[WickedAirSportz]

Where did you get the 30 balls figure? Yes, the syncronizing routine requires no less than 16 balls, but no more than 32 balls to syncronize, and is designed to work around a steady stream with little fluctuation in the ball spacing (about a 80ms window).

As far as the video goes, I did not video this event - it happened a year ago. If you notice on our website, it states 16bps (not 18bps), and has for a year. By your own admission, you have seen 16bps possible. If you spent years doing research, how come you have not come up with the fastest agitated hopper upgrade like I did in a few months?

By the way, a BYTE is not always 8 bits. That is the old school way of thinking. If you program assembly on a PowerPC processor, you are going to have some problems. A BYTE is 16 bits, a WORD is 32 bits, and a LONG is 64 bits, and a DOUBLE is 128 bits. In microcode technology, a BYTE represents the smallest path size of the execution pipeline.

[hitech]

Originally posted by WickedAirSportz
By the way, a BYTE is not always 8 bits. That is the old school way of thinking...In microcode technology, a BYTE represents the smallest path size of the execution pipeline.

You (and others) can re-define the term byte if you want. That seems to be what "kids" do these days, change things to fit their current situation. A byte is 8 bits.

Interesting choice of statments in my post to comment on...

[manike]

Originally posted by WickedAirSportz
Where did you get the 30 balls figure

Oh I'm sorry it's 32 balls... Thanks for putting the correction in on that point.

Originally posted by WickedAirSportz
As far as the video goes, I did not video this event - it happened a year ago. If you notice on our website, it states 16bps (not 18bps), and has for a year.

But you claimed it on a website... would you like me to quote you? again... So you have no video, and no proof that it is possible? Then how can you say...

Originally posted by WickedAirSportz on 24/08/01
You just can't argue with the fact that a gun set to shoot at 18bps (in full auto) empties the hopper in a just a few seconds, without breaks, chops, or misses. This is what we are seeing with the TurboRev upgraded hopper.

You can argue with it if there is no proof. If it was true at that time why does your website now claim 16bps? Surely you hadn't originally exagerated the truth had you?

you see once again you have no proof of your claims when you make them. I believe you reduced the number from 18 to 16bps after I called you last time. I'd even be interested in seeing a gun on FA empty a Turbo rev at 16bps "without breaks, chops, or misses" Surely that will be easy for you? There has never EVER been a video or proof of it happening. Isn't that a little strange when people usually can't wait to show off what their guns can do on the net?

Originally posted by WickedAirSportz
By your own admission, you have seen 16bps possible

Yes between two shots only, and purely as a lucky event, never as a reliable feed rate for a whole hopper that a gun could shoot on FA "without breaks, chops, or misses"

Originally posted by WickedAirSportz
If you spent years doing research, how come you have not come up with the fastest agitated hopper upgrade like I did in a few months?

Because I found that it wasn't possible to do with an agitating loader, and so went off and developed something else instead

manike

[mykroft]

WAS: I'm wondering if you ever looked at standard practice amongst players. String of over 16 balls are rare in the tournament scene, except for back players, and even then the strings tend to be shorter. As far as I can tell from your explanation of how the Turbo-Rev works, the adaptive algorithm is useless for 75%+ of the tournament scene, who tend to snap shoot strings of 3-10 balls.

So the adaptive algorithm would appear to be useless since it requires a steady string that's excessivly long, I would suspect you pick up most of the Turbo-Rev's performance the same way an X-Board does, by spinning faster & with more torque. Now if you store the data gathered, and got the minimum string down to 8 balls or so, I could see this working, but that would take more RAM than the PIC you are using has.

[314159]

Originally posted by hitech
And BTW, a byte is 8 bits, period.

the rom on the 12c508a is 512x12bits.... that's why i used the term words.

[WickedAirSportz]

WAS: I'm wondering if you ever looked at standard practice amongst players. String of over 16 balls are rare in the tournament scene, except for back players, and even then the strings tend to be shorter. As far as I can tell from your explanation of how the Turbo-Rev works, the adaptive algorithm is useless for 75%+ of the tournament scene, who tend to snap shoot strings of 3-10 balls.

You're absolutely right! I am a back player, and I do shoot long strings lasting sometimes 5 or 6 seconds. I find it quicker to just move your barrel as you are shooting then to stop shooting, moving your barrel, and then continue. The benefits of THIS PORTION of the AI will not help snap shooters. The previously mentioned AI, where the motor speed is adjusted based on the time between balls, does increase the feed rate (which apparently is not being disputed here).

So the adaptive algorithm would appear to be useless since it requires a steady string that's excessivly long, I would suspect you pick up most of the Turbo-Rev's performance the same way an X-Board does, by spinning faster & with more torque.

The x-board does not increase the speed or torque. They just changed the delay time on the start up, and reset the LED blinking on a low battery condition. Those are the ONLY changes with the x-board when comparing the code from original boards to the x-board, side-by-side. The PICs were never locked in any of their boards, so you can check this out yourself.

Now if you store the data gathered, and got the minimum string down to 8 balls or so, I could see this working, but that would take more RAM than the PIC you are using has.

Percisely why the TurboRev II uses the newer PIC that has 1K of code space, more RAM, and EEPROM (for storing table pointers), an A/D converter for feedback on the motor torque level, and real interrupts.

[Miscue]

Originally posted by WickedAirSportz
Do you want the hopper to feed fast? If so, you need to determine the optimal speed/torque for the motor (at the very least).

A very simplified form of hopper AI can be viewed like this:

The time between balls is clocked in, and an average over a period of time is recorded. Now, increasing and decreasing the motor speed is going to affect that average. So, the software can determine what the best possible speed is to allow the balls to flow the quickest.

This method alone works great, but it can not deliberately accelerate the stack of balls, although this does happen on occassion as you see a spike in the timing chart.


Miscue, you and others asked for an explanation (proof) of how the TurboRev technology works. I am providing that to you. If you intend to make smart *** remarks, then I won't waste my time.

This is not proof... extremely vague.

Replace "hopper" with "popcorn popper." This popcorn popper has an agitator connected to a motor.
.
.

Do you want the popcorn popper to pop fast? If so, you need to determine the optimal speed/torque for the motor (at the very least).

A very simplified form of popcorn popper AI can be viewed like this:

The time between kernel pops is clocked in, and an average over a period of time is recorded. Now, increasing and decreasing the motor speed is going to affect that average. So the software can determine what the best possible speed is to allow the popcorn kernels to pop the quickest.

.
.

You could replace "hopper" or "popcorn popper" with microwave, dishwasher, lawn mower, blender, etc... and it would follow the same logic. Actually, pretty much everything you have said has similar problems.

If you had explained WHY... then this template would not be interchangable. The WHY's for why a hopper, popcorn popper, etc. will be different - and are not interchangeable.

This is what's happening. You are making the square peg fit the round hole. You don't even know the WHY's yourself. What you think and say is make-believe... imaginary. I believe that you believe what you say is true - and in this there is no sense in arguing. What do you say to someone who says the earth is supported by a large tortoise? "What does that tortoise stand on?" "Oh, it's tortoises all the way down!"

Sure, you may be good in field X... but that does not make you good in field Y, which you are trying to do w/o success.

I'd stick to coding... and leave the subject of "reality" alone.

[WickedAirSportz]

If you had explained WHY... then this template would not be interchangable. The WHY's for why a hopper, popcorn popper, etc. will be different - and are not interchangeable.

One step at a time. You have to learn to walk before you can run.

I will explain why. I have already posed several questions that have gone unanswered. I am certainly not going to give out the source code as your example, I want everyone to learn something from this... which is the way I would be able to prove that I do know WHY this works.

[hitech]

Originally posted by 314159
the rom on the 12c508a is 512x12bits.... that's why i used the term words.

And you would be using the term correctly.

[manike]

Originally posted by WickedAirSportz
I have already posed several questions that have gone unanswered.

How strange, I was just thinking exactly the same thing. People might get mistaken and think you were avoiding answering the questions and posting proof...

but surely that can't be the case... can it?

Your attempts to act like a 'know it all professor' are condescending and pathetic.

Put up or shut up. How about the Turbo Rev on your new intimidator with Equalizer board... surely that would get the best possible performance out of the turbo rev

manike

[hitech]

Originally posted by manike
How about the Turbo Rev on your new intimidator with Equalizer board... surely that would get the best possible performance out of the turbo rev

Because it won't work?

[314159]

Originally posted by WickedAirSportz
One step at a time. You have to learn to walk before you can run.

I will explain why. I have already posed several questions that have gone unanswered. I am certainly not going to give out the source code as your example, I want everyone to learn something from this... which is the way I would be able to prove that I do know WHY this works.

i agree with wickedairsportz. for example, obtaining the code without knowing what it's aim is would be like trying to play sokoban without knowing the destinations. you would see a bunch of info being moved around and a bunch of bits being set....

i will play

Originally posted by WickedAirSportz
why does the TurboRev feed faster than any other aggitated hopper in existance?

first, assume that no paint is being fed, and the paddles were spinning all the time. the paint in the hopper would be continously spinning around. the paint moving around in a circle would have it's momentum traveling around in a circle in the direction of the propellers. this would probally result in skipping, bobbeling.... and resist gravities pull to feed it down.

it seems the most advantageous way to move the paddle would be just enough to ensure a couple balls go over the feed port, then abruptly stop it, just as the gun is firring, before the ball in que in the ball stack clears the senor, tripping it. then repeat it before the next estimated shot.

of course if the rules that are set up for the pic to spin the paddle make a wrong guess when to spin and stop the paddles, (it could detect this by verrifing the time the sensor should see a gap), it could spin for xxxx amount of time like the revvy does. and have the same preformance as a revvy.

this would not be a total loss, because the rule set would take this into account trying to adapt for the next shot fired.


P4ULuk, stop being retarded.

[Emagster]

wow...that was great miscue. Not that i know diddly squat about all this odd termonology...but it sounds good from what i got out of it