2252 High Speed Video

[ayeckley]

I've just now had a chance to upload some of the high speed video we shot last week of our shooter mechanism. It's fun to look at, but hopefully it will also help folks understand the wheel/ball interaction that is going on in their own designs. We've already made some changes to our setup as a result of studying these and should be taking new video later this week if anybody is interested.

Test 1: http://youtu.be/pkIgCc0uCUo
Test 4a: http://youtu.be/WvU6aOwHeMA
Test 5: http://youtu.be/b7IH0u9zDUc
Test 7: http://youtu.be/fZ4H6cGPZqc
Test 10: http://youtu.be/DoPc40vsIsY
Test 11: http://youtu.be/egLupJ1duyI

[one4robots]

Cool use of the camera...thanks for sharing!

[Ether]

Wow. Great videos.

A host of questions spring to mind:

Where did you get that camera!!?

Why no backspin?

Why two powered rollers instead of one+chute?

How fast are those wheels spinning?

What type of calculations are you planning on doing in software to adjust the shooter? e.g. lookup table using test data, equations of motion, math model with parameters tuned based on test data, something else?

[ayeckley]

Originally Posted by Ether

Where did you get that camera!!?

I convinced the management of the company I work for to allow the kids to come in and use it after hours (with heavy supervision). We purchased it a year or two ago to support a test program in which we visually determined the response time of a cryogenic propellant fluid level sensor as it was immersed and withdrawn from baths of liquid hydrogen, liquid oxygen and liquid nitrogen. Now that the project has wrapped up we're left with this somewhat underutilized capability.

Why no backspin?

The intent was to have backspin, so the rollers are driven at differential speed (I don't have the exact ratio handy at the moment, but it was less than 10%). We also expected drag from the "guide antennae" to impart a bit of backspin as well. One of the things we hoped to learn by shooting this video was why we weren't achieving the backspin that we thought we should be getting. I'm pretty sure the answer is in the footage from Test 4a; the ball "jiggles" it's way through the vertical transport before entering the throwing wheel nip point and as a result the differential wheels are simply cancelling out "forespin" that we didn't anticipate. We added a guide bracket yesterday to prevent this jiggling and instantly we saw the apex of our trajectory increase (based on just plain observation). I'm hoping we have time to study it this weekend to see if we've improved our backspin any; it's hard to tell with the naked eye given the low ceilings in our main work area.

Why two powered rollers instead of one+chute?

In 2009 (in which we did exactly that) we found that a lot of energy was dissipated via the Orbit ball skidding against the stationary "chute" surface. We also considered that a single-side drive could potentially give us more backspin than optimal. By coupling the two rollers via a belt we could reduce friction losses and tailor the differential velocity if needed by swapping out sprockets. We haven't done that yet.

How fast are those wheels spinning?

Should be very close to 2000 RPM (based on design as well as encoder measurements). The wheels are 4" in diameter. We've got both open and closed-loop control modes available for wheel velocity; the videos were shot in open loop mode. One thing that we changed early on was to add masses to both wheels to increase angular momentum; this had a significant positive effect on range, as would be expected. They are made from 3.5" hex stock -- the facets can be seen flashing by in most of the shots.

What type of calculations are you planning on doing in software to adjust the shooter? e.g. lookup table using test data, equations of motion, math model with parameters tuned based on test data, something else?

We've got the ability to implement all of those and more. To us, accurate rangefinding is a prerequisite to using a math-based approach to set wheel velocity. For better or worse, we're finding (and I think I reported it in an earlier post) that the MaxBotics sonar range sensor seems to be susceptible to high freqency ambient noise (such as F-P motor commutator-pass, gear tooth mesh, etc.). So much so in our experience that we don't believe we're going to be able to use it in competition for reasonably accurate range detection. The next best option for us is rangefinding via the camera, which is our current emphasis. We consider that a relatively high-risk approach however since the lighting conditions at the regionals are notoriously difficult to replicate. There are a few other rangefinding options available to us but each is less attractive than the last.

It's safe to say that we are not going to hang our collective hats on achieving reliable and accurate rangefinding and at a minimum we'll have a set of preset speeds that correspond to fixed points of reference on the field. The optimum speeds will be determined experimentally -- somewhat at leisure -- since we're able to build a practice bot this year.

[Ether]

Originally Posted by ayeckley

...

Great post, thanks for the detailed answers.