Re: Team Update #18
 

I considered interrupts, but even interrupts have a minimum latch time on most systems I've used, it may be on the order of microseconds, but it's there, and the point is, it was omitted, so we don't know if it's a fast interrupt or a slow poller, or a shift register that only gets clock in every 300ms, etc. The system must have some time component to it, which was my point. To assume it can behave instantaneously was erroneous, especially since no time component was specified. If you told me it took 100us for the interrupt to latch and take hold, then I'd say it's a negligible amount of time, but at least I'd have concrete evidence to work with.

EDIT: As also pointed out before, even interrupts cannot guarantee a clean signal without some decent debounce time on the signal, which still brings you back to a time component. Which we weren't given, and FIRST may not (yet) have.

Matt

Re: Team Update #18
 

Beat me to it. We ran the math in metric units, but it's the same nonetheless.

We then assumed instant acceleration, and used distance = velocity x time to solve for an approximate "perfect" time.

Re: Team Update #18
 

It'd get shut down a lot faster if we went with my own personal choice of entrance music, Shots by LMFAO.

Re: Team Update #18
 

For reference I'm linking to a post made a couple hours earlier here in this thread.

Re: Team Update #18
 

I recall your post, though I don't think my post was unqualified, merely incomplete. I should have mentioned interrupts in my original post, I was thinking more conceptually (against the notion of instantaneous detection taking zero time) and didn't see much relevance at the time.

Matt

Re: Team Update #18
 

Continuing the calculation:

(16.8 watts @ max power)/(0.0475 Nm torque @ max power) = 353.7 radians/sec shaft speed @ max power

(10.8 ft/sec)/(353.7 radians/sec) = 0.03045 ft shaft radius = 0.73 inch shaft diameter (for direct drive)

Probably want to reduce that diameter by 15% or so for losses and margin

someone please check my math

Re: Team Update #18
 

Poor word choice on my part; the word has multiple meanings which could be taken the wrong way. I intended definition #2:

I referenced the previous post mostly for the remarks about debouncing interrupt-serviced switches.

Re: Team Update #18
 

Folks,

If I were to carefully read this entire thread, instead of only quickly scanning the last 100 or so posts, what useful information/conclusions would I acquire?

I have gathered that the tower targets are close to FUBAR status and many mini-bot designs are consequently pseudo-randomly finding themselves up the proverbial creek. It that all we have here?

My goodness, does it take 200+ posts of grouching at each other, and at FIRST, to convey that clearly?

I know everyone is tired, but this could be a fun topic.

Who has tested some work-arounds and can reports their results to teams that need to modify their mini-bots???? Is slower better? Would putting a broad squishy nose on a mini-bot help? Would leaving the mini-bot motors energized an extra few fractions of a second after target-contact help? Anything else?

Blake

Re: Team Update #18
 

I don't believe this has been 200 posts of people grouching at each other, instead it's been a very lively, interesting debate of the technical details of the situation. And since this is just coming out now, nobody has publishable results yet, just a lot of hypotheses on what may or may not be occurring, and how to possibly improve the towers or minibots.

Nobody has a definitely answer for you, other than expect to have to work at this some more.

Personally I think this group has done a fantastic job dissecting the situation and working to figure out the information FIRST has woefully failed to provide once again, but give them a chance, this isn't old news yet.

I thought it was a fun topic, though I wish I could contribute more effectively to it.

EDIT: I wanted to answer to this as well.
Sorry to misunderstand you, your intended wording makes a lot more sense!

Matt

Re: Team Update #18
 

There is a large number of posts because it is a topic of interest and importance to everyone, not because folks are looking to grouch at each other. The volume, to which you have contributed, is an accumulation of many individuals, of which you are now one. It is the result of many people sharing their 2 cents, like you did. Nearly every post has dealt with the topic, the only one I've read that really grouched at others is yours.

Re: Team Update #18
 

Here's a different way to get at approximately the same point.

At kick off, the video of the FIRST built minibot showed about 1.3 ft/sec for a robot that looked to be more than 5 lbs and using a pair of Tetrix motors and gearboxes.

Its not hard to cypher that a 2 lb robot can be 2.5 times faster than a 5 lb robot. By the same token, if you throw away a near 50% inefficient transmission, you should be able to obtain another doubling of speed. That gets you in the 7-8 ft/sec range. Add additional lowering of friction in the attachment to the pole mechanism and you approach the magically 10.8 ft/sec. Add topping off the battery to get to a better motor curve is gravy on top.

Re: Team Update #18
 

Just as a note:

We had 3 minibots up the pole today at the Detroit district, all three triggered just fine. I'll keep my eye on it this weekend.

Re: Team Update #18
 

Were any additional modifications made to the towers since the last time this field was used? What was the last event this field was used at?

Re: Team Update #18
 

Thank you Ether! This is the first post I've seen all season to do a proper (yet quite simple) calculation of how fast a minibot of given weight can get up the pole. I've been meaning to do this with my students all season long, but was too busy with the arm and other things. I think now is the time to revisit it.

Trial and error is one thing. Knowing what you're shooting for, because you did some calculation first, is quite a different (and much better) thing.

Re: Team Update #18
 

The field from Waterford went to Detroit.