Re: Team Update #18
 

I think we have one ref concentrating on every tower anyway looking for penalties and disablement.
I think we can trust ref's to press an "enablement" button as soon as the minibot crosses the starting line, then use the sensors on the plate integrated over 40 milliseconds to record the time I.e., the tower plate is inactive until after the ref decides the minibot crossed the start line fairly.

Whatever the triggering mechanism: it NEEDS to be published and the sooner the better. If not, then some teams will end up getting an advantage over others because of the multiple hats of developers, testers and facilitators.

Re: Team Update #18
 

I don't want to seem too flippant but YES - because that is how the real world works. It is not fair and/or uniform. Go thru a career as an engineer who assumes the provided specs are always perfect and you will lose a lot of money and be frustrated. You'll probably quit and end up a sales-person!! ;o)

Re: Team Update #18
 

We continue to monitor the impact of Copioli-isms in Texas, shoring up weaknesses in mounting pressures and potential collisions caused by strong wind. In other words, we are doing the best we can with what we have to work with. Temps are still spiking in some areas but we're continually adapting in preparation for the next generation. :)

Jane

Re: Team Update #18
 

AFAIK, we do not have official drawings or specs (of the sensor) from FIRST so I cannot say this definitively... but if the drawing that was posted earlier in this thread by colt527 is a reasonable representation of the hardware then the minibot moves the plate 1/4" and then closes the "switch" (which appears to be 2 metal pieces coming into contact) which acts as a hard-stop. High speeds of impact into this hard stop could arguably mean less contact time, not more.

The damping mechanism was suggested earlier in this thread by Squirrel (minibot) and jspatz1 (tower).

Everyone agrees that requiring multiple consecutive positive samples lowers the incidents of false positives.

The comment about interrupts was simply a clarification, for the benefit of students who may be reading, to an unqualified statement made about sampling. It may or may not be part of an eventual solution. Another clarification: an interrupt does not have to be "held". The ISR can spawn a high-sampling-rate temporary thread to run an algorithm to test for false negatives. Then it's just* a matter of adjusting the software.



* "just software". I hate that phrase. Don't you?

Re: Team Update #18
 

Yea, I was close to squirrel's idea with a slightly different idea that was totally ignored. Jspatz's damping idea looked like an entire rework that introduced as many questions as it had answers. But that's neither here nor there at this point. The math and the arguments solidify that a simple damping mechanism is probably the simplest way forward from both a technical and a holistic program perspective. Personally, at this point, I'd much rather implement the damping mechanism myself rather than expect the numbers FIRST puts out are perfect and without tolerance. We still need test time on Thursday though. I don't exactly have a "springy finger" or "squishy surgical tubing" down to a mathematical science yet.

Re: Team Update #18
 

I'm thinking the root cause of the problem is more related to the rate of evolution of minibot designs. With the full-size competition robots, even when teams see robots with really amazing features, they are just too complicated to copy in the time available. The design time of one iteration of a minibot is fairly short and teams which so choose can keep iterating as long as they want. My guess would be that the GDC envisioned 4 or 5 second minibot times and the triggering system on the tower would have been fine. Early in the build season, talk of 3 second minibots surfaced. Then 1625 posted their video and the times fell to 2 seconds and now times near 1 second have been demonstrated. Put 2000 teams on a problem and allow them to iterate over and over again and give them a big payoff or iterating over and over and the result is that by St. Louis any team that wants an awesomely fast minibot will have one and maybe they all will exceed what the GDC envisioned.

Re: Team Update #18
 

Within a few hours of the update clarifying we had to use FTC motors, we had already calculated (with darn simple math), that sub 1 second minibots were possible. This should not have been overlooked, that's as if they made a field border that could only handle impacts of robots going 7 ft/s, because they assumed none would go faster.

Re: Team Update #18
 

Would you be willing to post this math, for the benefit of students on teams who do not have mentors/teachers who know how to do motor calculations.

Re: Team Update #18
 

I hear what you are saying and it seems reasonable, but if the GDC anticipated 1 second minibots it seems like they should have built some and tested them on their triggers. Most team minibots were probably "tinkered" into existence rather than engineered into existence. Is it possible that the GDC did likewise?

Re: Team Update #18
 

16.8 watts max power output w/o gearhead

= 12.4 ft-lb/sec

x2 motors = 24.8 ft-lb/sec max power output

2.3 lb estimated robot weight

(24.8 ft-lb/sec) / (2.3 lb) = 10.8 ft/sec (neglecting friction)

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.

Re: Team Update #18
 

Update from Peachtree:

We deployed our minibot in 2 practice matches, and had no issues triggering the tower. For reference, the minibot weighs about 2.8 lb.s and runs the pole in about 1.6-1.8 sec.s We are using a 3-way household light switch to turn off the juice and short the motor leads for the return trip. I haven't measured the force required to flip that switch, but it is more than 4N.

Re: Team Update #18
 

I believe Ether's number are based on actual lab trials.
I.e., the specification provided by Tetrix was no where near sufficient to extrapolate to a 10.8 ft/sec estimate. It was only a team member that went in a lab with dynamometer capability and did lab trials with and without the gearbox attached that allowed for the calculation.
Thank Richard for the creating the data AND sharing the data that allows physics teachers to let this rise above tinkering status.
http://www.chiefdelphi.com/forums/sh...+dynamomet er

Re: Team Update #18
 

He (along with many others) already thanked Richard in post#5 of the thread you linked. But thanks once again, Richard :-)

Be aware that the calculation does not include any consideration of the time it takes the bot to accelerate to the indicated top speed. So if you use the top speed to calculate how long it will take to get to the top of the pole, the answer will be optimistic.

I'm going to take a look at a calculation that includes acceleration. I'll have to eyeball data from Richard's power vs torque curve (I didn't see raw data posted anywhere - is it available?). From other Tetrix curves I have seen, the motors are a lot less linear than other motors we've worked with, so I'll least-squares-fit a polynomial. Since the torque depends nonlinearly on speed, and the speed is the integral of acceleration which in turns depends on torque it's an interesting differential equation.

Re: Team Update #18
 

He was giving you credit for seemingly being the first to provide the physics formulas I think Richard had provided that in post #7 of that now famous thread.

I guess there is always a healthy back and forth between thinking of the academic physics (thought experiments) and going into the lab to make fundamental measurements AND sharing them.

Those that have sophisticated tools like a dynamometer and share the results with everyone are making the math/physics very valuable.
Speed is a relatively easy thing for most teams to measure: actual motor performance is not and the vendor published curves are not always sufficient to the challenge.

FIRST also inadvertently made understanding of physics more important in the trigger mechanism. It's all good. There are physics lessons everywhere.

Re: Team Update #18
 

Going through the thread and looking for last week's events:
San Diego had issues (Cory (254), Jon (987))
Waterford worked okay (Kara (1189) (assume this is where she was), Zach (2337))
Wisconsin worked fine (Al (111))
Kansas City had issues (Jeff (1986))
Pittsburgh seemed to work (Ken (527))
Florida worked mostly (Alex (744), Jared (341)), Jared mentioned some issues, but did not have specifics
Lake Superior worked (me (next to the field all four days))
WPI had an issue for team 358 but few other issues (Chris (2791))
NYC and Israel have no reports in this thread.

For this week:
Detroit has had success (Chris (51))
Peachtree is working (Martin (1771))

Re: Team Update #18
 

Here's a fun image, generated here. Red line is Ether's theoretical diameter, and the motor load is indeed at max power. Yet the iterations show that a slightly different diameter can squeeze out a bit more due to acceleration being a slightly larger-than-anticipated factor.

Assumes:
Battery voltage of 14.4V
6755 RPM Free Speed
0.095 Nm Stall Torque
(Extrapolated the stall/free currents based upon a realistic efficiency curve)
2 motors

100% wheel-to-pole efficiency
direct-drive minibot straight off the motor
2.3 lb weight
Minibot goes exactly 7.5 feet straight up

Re: Team Update #18
 

Not to start an argument here Dick, but the calculation I provided is somewhat different from the one Richard posted in #7. It's more similar to the one jreuter posted in #25. For the record, I hadn't read either of those posts until just now when I went back to re-read the thread after seeing your post. So Kudos to Richard and jreuter. I invite anyone interested to read that entire thread.

Does anyone know if raw (numerical) dyno data has been posted anywhere, which includes motor current and speed?

Re: Team Update #18
 

While I'd normally take Al's word like one might of God, I'm not sure if this is true. There was an elims match where 234 deployed a minibot which didn't trigger, but definitely made it to the top. I was in the pits (save for 1675 matches), so this might've been the only time (freak incident or something like that).

Re: Team Update #18
 

I reported only our experience at NY. There was one instance where our minibot did not trigger the top, but it was counted. All of our other deployments wee successful.

Re: Team Update #18
 

In the match you're referring to, 234's minibot was moving up the pole so slowly that I doubt it hit the top with enough force to trigger the sensor. From what I saw, it pretty much died as it hit the top, if it even reached the top. All minibots that I saw climb the pole with decent speed, triggered the sensor.

Re: Team Update #18
 

Yeah, the head ref had to take out a ladder and a piece of paper to determine if there was space inbetween the minibot and the top of the tower. The decision would have determined the match (and who advanced to the semifinals) if it wasn't for a red card on the other alliance.

Re: Team Update #18
 

This graph matches our experimental results. Our climb time was minimum at .40" dia.

Re: Team Update #18
 

Just witnessed a false positive on the Bayou webcast. Minibot was about halfway up the tower when the lights triggered.

Re: Team Update #18
 

Katie,
I discussed this in another thread I think. I was in the scoring area about ten feet from the minibot. It was spinning it's wheels as it climbed and when it reached the top, the wheels continued to spin but not enough force was applied to the plate. The Head Ref performed the paper test and initially determined that it had reached the top. Then he remembered a ruling about moving the plate. After checking the rules, I watched him and the rest of the refs do this, they determined that the plate had to move. Although I was not close enough to hear the refs conversation, I was sure that there was a a ref at the base of the tower when the minibot went up. A second check proved that the plate didn't move when the minibot was removed from the tower. His change in ruling was based on this second and critical check.

Re: Team Update #18
 

I wasn't sure. I was on the sidelines rooting for their alliance. Thanks for clearing that one up :)

Re: Team Update #18
 

Actually, that's quite good. You're right: any bot with the potential of winning the match (being the first to the top) will have enough velocity to trigger the pole. A lighter robot, unless it had an illegal battery or power source, would not have the velocity to create enough force, and the larger robot would being expending force on getting up the pole, therefore sacrificing velocity.

Re: Team Update #18
 

Keep in mind, there may exist a design in which the minibot is accelerated (reaching top speed) before it ever gets to the pole...

But how much did your minibot weigh during this test, which found this diameter to be optimal?

Re: Team Update #18
 

Not sure if someone has updated everyone, but we have not had any issues at West Michigan so far :)

Re: Team Update #18
 

Peachtree update:

No false positives, no false negatives (that I witnessed). Every minibot that made it to the top of the tower triggered the tower. It looks like, for peachtree at least, all this worry was for naught.:)

Re: Team Update #18
 

That's wonderful!

Re: Team Update #18
 

Impossible event since everything was fixed according to the update:rolleyes:

Re: Team Update #18
 

I don't think so. When it grabs the pole it will slow down and then accelerate again. It can't climb faster than it can free spin or even travel horizontally, not on Earth anyways.

Re: Team Update #18
 

I've seen a couple of teams (190 at WPI) with a clever deployment design that uses the same sized pipe curved to mate to the tower.
The minibot starts out accelerating downward off the hostbot (gravity a plus), then follows the curving pipe to start up the tower at full speed.

Re: Team Update #18
 

<G19> MINIBOTS must remain completely autonomous and move up the POST solely through electric energy provided after the start of DEPLOYMENT by the permitted, unaltered battery and converted to mechanical energy by the permitted unaltered motors (and associated, appropriate circuitry). Violation: The TOWER on which the MINIBOT is DEPLOYED is disabled. If the MINIBOT is DEPLOYED on something other than a TOWER, then the ALLIANCE’S TOWER upon which the highest RACE SCORE was earned will be discounted.

<G19> means that HOSTBOTS are not allowed to launch the MINIBOT up the pole at the TARGET, or otherwise contribute to the vertical movement of the MINIBOT. Energy for vertical movement may not be stored in the MINIBOT before DEPLOYMENT (except that which is contained within the battery and excluding incidental kinetic energy stored in the motors or wheels, but NOT, for example, in a flywheel).
(My highlighting, not FIRST's)

Since DEPLOYMENT starts when the miniboot crosses into the cylinder, it cannot have energy other than "incidental" kinetic energy in the wheels.
Incidental horizontal running starts prior to crossing into deployment-i.e., the length of the minibot will probably be overlooked as incidental.

Converting the horizontal energy produced by the minibot while over the cylinder is allowed: so the speed at the point of crossing the start line for a ramp can be higher than a minbot that uses an arm to place the minibot on the pole. I think a ramp bot can reach a higher top speed but the question is how much faster can other mechanisms get the bot to the start line as compared to the ramp bot. If the non-ramp bots do not start with a significant lead, the ramp bots can pass them (Assuming equal efficiency).

Also of note: the ramp needs to be well below the start line such that none of the minibot is in contact with it when any of the minibot crosses the start line.

My bet is that a ramp bot will record the fastest time. (We do not have a rampbot: at least not yet ;))

Also of note: rampbots need to demonstrate that their hostbot does NOT provide horizontal momentum to the minibot: E.g., a host bot that suddenly decelerates as it is reaching the tower and is not completely motionless as it deploys the minibot COULD be imparting non incidental kinetic energy. Referees will need to watch out for that.

Re: Team Update #18
 

In my opinion, this is illegal per the rules mentioned above. The hostbot is providing a track that is pushing the minibot up vertically.

Re: Team Update #18
 

West Michigan from what I know found no problem with Team Update 18. From what I remember all minibots that went up scored.

Re: Team Update #18
 

Update from Seattle Cascade:

Today there were no false positives in 64 matches on the Seattle Cascade field. If I remember correctly, there were two instances where a minibot successfully reached the top of the tower, but did not trigger the sensors. In both instances, the referees followed the latest Team Update and did not score it. Both of those minibots scored at other times throughout the regional.

Re: Team Update #18
 

But the power is coming from the minibot. I therefore believe that it is legal. This would be an interesting topic in the "You make the call" section.

Re: Team Update #18
 

I've never thought of it that way, but I can't argue with that...

Sucks to be 190 and 233 I guess.

Re: Team Update #18
 

Be careful to paint both teams with the same brush stroke. Mark made a specific description of 190's deployment which made Paul think it's illegal, namely the creation of potential energy by the downward movement along the track. From my understanding, Pink's ramp only goes upward, meaning the track (and thus the hostbot) would not be contributing any energy.

Re: Team Update #18
 

Good point.

For what it's worth, 190's track begins horizontally like 233's track - the minibot is the sole source of energy.

One could make an argument that the robot converts the horizonal motion of the minibot into vertical motion, but that's a bit of a shaky justification.

Re: Team Update #18
 

An update from Detroit:

All of our minibot runs triggered the tower. Everyone that I saw triggered the tower except one:308's minibot failed to trigger once and it cost them the match. I'm not sure if it hit the bolts, but it hit the plate with more than adequate force. They have a very reliable minibot that triggered every other time they ran it.

I think I may have saw one false trigger, but I can't confirm.

Re: Team Update #18
 

I would say that if the track is horizontal and fully below the deployment line it is legal. However, if it starts above the deployment line, uses gravity to gain momentum, then deploys below the line, I would say it is illegal because it used potential energy to impart vertical motion.

Re: Team Update #18
 

As a devil's advocate, I'm still not sure even that is legal. <G19> specifically says "...solely through electric energy provided after the start of DEPLOYMENT by the permitted..." As the 190 design has the robot accelerating through electrical energy prior to deployment (crossing the plane of the base) I could see the argument that they are storing "non-incidental" kinetic energy in their minibot. Probably the only way to get the real answer is the Q&A. Does 233 start their minibot within the base? I'm pretty sure 190's did not.

It wouldn't be an FRC game if 190 didn't do something that CD could argue the legality of for entirely too many posts!

Re: Team Update #18
 

In this case, 2 lb. 9 oz.

Re: Team Update #18
 

I see it slightly differently:
The track PRIOR to the DEPLOYMENT cylinder needs to be horizontal (or upward) and should not be longer than the length of the minibot (plus a grace distance of couple inches). Long horizontal tracks spanning the HOSTBOT would violate <G19>.

The shape of the ramp within the deployment cylinder can be any shape because the shape does not create additional energy.

If a team uses a ramp, the HOSTBOT must remain perfectly stationary while the MINIBOT is moving on the RAMP, otherwise it is not clear if the HOSTBOT is adding energy to the MINIBOT.

Re: Team Update #18
 

Seems to me that "...solely through electric energy provided after the start of DEPLOYMENT..." is pretty darn unequivical. No other form of propulsion energy can be used, even if it is the robot's own potential energy. Just because acceleration from gravity is free does not mean it is allowed. This would certainly qualify as energy other than electric energy, and if I understand the description, would also be partially gained before deployment (before crossing the cylinder of the platform.) This is one of those cases where you are just going to have to live with the "spirit of the rule."

Re: Team Update #18
 

Anyone know of a video for the 190 or 233 deployment system in action?

Re: Team Update #18
 

If the ramp shape causes a net elevation drop in the minibot before it reaches the pole, then additional energy other than "electrical energy from the motors" (in this case the minibot's own potential energy due to gravity) has indeed been imparted on the minibot.

Re: Team Update #18
 

I haven't heard of any problems at AZ. Our minibot did not trigger the second time we deployed...but we did find our charger, and we think it will make it further up the pole next time.

Re: Team Update #18
 

...move up the POST solely through electric energy provided after the start of DEPLOYMENT by the permitted, unaltered battery and converted to mechanical energy by the permitted unaltered motors...

As long as gravitational potential lost plus gravitational potential gained is zero or negative below the deployment line- it provides NO ENERGY "to move up the POST". All energy is coming from the batteries/motors- but the allowed advantage for the rampbot is that its battery/motors energy expended as soon as it crosses into the deployment cylinder can be transferred through any shape ramp into vertical motion up the pole.

Re: Team Update #18
 

yes

Re: Team Update #18
 

I envisioned from some of the descriptions a ramp with a net downward slope that allowed the bot to gain momentum from elevation change. If instead you are saying that the minibot gains momentum between the deployment cylinder and the pole by simply using its own motors to get a "head start" and then the track directs this momentum upward, then I would say that is legal, and a clever idea.

Re: Team Update #18
 

Seems I have heard that somewhere before...

As for the 190 design, if the curved pipe does not contact the tower above the 18" mark there is no violation there. The minibot is using the electric energy stored in it's legal battery to drive so no violation there. The GDC has ruled that the motors on the minibot can be running prior to deployment so there is no violation there. However, G19 may apply if it can be proven that gravity is actually adding to the minibot's ability to climb the pole. I cannot see that a downward movement on a pipe adds anything to the upward motion of the minibot. What goes down does have to come back up afterall.
<G19> MINIBOTS must remain completely autonomous and move up the POST solely through electric energy provided after the start of DEPLOYMENT by the permitted, unaltered battery and converted to mechanical energy by the permitted unaltered motors (and associated, appropriate circuitry). Violation: The TOWER on which the MINIBOT is DEPLOYED is disabled. If the MINIBOT is DEPLOYED on something other than a TOWER, then the ALLIANCE’S TOWER upon which the highest RACE SCORE was earned will be discounted.

<G19> means that HOSTBOTS are not allowed to launch the MINIBOT up the pole at the TARGET, or otherwise contribute to the vertical movement of the MINIBOT. Energy for vertical movement may not be stored in the MINIBOT before DEPLOYMENT (except that which is contained within the battery and excluding incidental kinetic energy stored in the motors or wheels, but NOT, for example, in a flywheel).

Re: Team Update #18
 

It could if implemented well.

If the minibot on the host is higher than the deployment line on the tower pole then in theory the difference in height is potential energy that gets converted into kinetic.

It all depends on whether the friction loss traveling the curve pipe is greater than the KE gain due to the added PE.

Re: Team Update #18
 

I think, in the context of the rule, it's irrelevant whether the the ramp on the hostbot starts above or below the deployment line. If the minbot loses gravitational potential on its run up to crossing into the cylinder of deployment, and the minibot design converts horizontal into vertical motion, then my read is it is in violation of <G19>.

I would imagine that most design have the ramp start BEHIND the deployment cylinder in order to get everything lined up prior to the 10 second mark: I think such designs would need to be completely horizontal or uphill prior to crossing into the cylinder in order to stay within the confines of <G19>

Are there any pictures or videos available of the various ramp bots?

Re: Team Update #18
 

You misunderstood the point I was making, which was simply that if the minibot starts at a point on the hostbot above the height of the deployment line on the tower pole, then the conversion of this stored potential energy into kinetic during the downward movement on the hostbot track could in theory add to the upward motion of the minibot on the pole. I wasn't suggesting this was legal or suggesting it as a design strategy.

Re: Team Update #18
 

OK Ether, you run the numbers and give us a report on how high that pipe inside the robot has to be before there is a payback for the added weight, length of travel and increase in speed that makes a difference in the time it takes to get to the top. Make sure you include data on how long it takes for the minibot to cross the plane of the tower base as it begins it's downward travel and how long it takes from that point to actually hitting the top.

Re: Team Update #18
 

My mistake, my apologies: I was assuming you wanted to focus on physics within the confines of the rules as opposed to broadening the scope of the discussion outside the game.

A legal ramp can work a bit like the blocks in a runners race, allowing the motors to get to the range of most work within the power curve, faster.
Does that speed to the best part of the motor curve exceed the extra work needed to cover a longer path? Probably too complicated to be discoverable by mathematical analysis of easily measured parameters.
Testing it directly would be the only realistic way to know.

Assuming a single speed transmission, I would guess that one can compute a drop angle and distance that optimized the time to the best part of the motor curve- at that point, I don't think there is an advantage of continued downward trajectory. In a sub 2 second race, getting to optimum portions of the motor curve faster (let's guess 1/10th of a second) might have measurable advantages at the finish line.

In such cases, front wheel drive can have a significant advantage!

Re: Team Update #18
 

OK guys, I'll give it one more shot. Al made the statement "I cannot see that a downward movement on a pipe adds anything to the upward motion of the minibot". I was simply stating that it can*. I don't know whether or not it's legal, and I don't think it's the best strategy to pursue (for a number of reasons).



* It's not about the robot. It's about science, technology, engineering, and mathematics.

Re: Team Update #18
 

For what it's worth, the slowed down version of our non-ramp minibot climbing a slightly shortened pole in about 1.5 seconds shows it accelerating significantly through at least the first second. I'd extrapolate that it is not reaching the "most work" portion of the motor curve within the first half second. (I.e., a significant portion of the race time).
Probably time to lessen the diameter of the wheels.

http://www.youtube.com/watch?v=KLZCNbcNopU

Sure wish we still had license access to Dartfish video analysis software...
(It's a physics rockstar)

Re: Team Update #18
 

Of course it can. Imagine a car with no motor gaining speed coasting down a steep hill. As it reaches the bottom, it begins a race with a car with a motor that was standing still, and they race up the next smaller hill. The car with no motor can win with initial velocity and energy gained from the first hill.

Re: Team Update #18
 

For physics and/or math students who may be interested, I just posted a short write-up showing how to setup and solve the differential equation for the MINIBOT accelerating from a dead stop up the pole. An analytical solution is given so you can just plug numbers in using a calculator (if you have the patience), or better yet a spreadsheet.

The model ignores friction, which may be a significant factor, but the physics (and math) is nonetheless interesting and useful for gaining insight and rough approximation.

http://www.chiefdelphi.com/media/papers/2470

Re: Team Update #18
 

First instances of this came up... At West Michigan District, 67 clearly made it up the tower probably second of the four and didnt set of the light, and where not given any points... Didnt effect match results...

Re: Team Update #18
 

As a member of team 190, and having built the robot, the ramp does not go downward, but slopes upward. The motors turn on only after the 10 second mark. The entire system is below the deployment line.

Re: Team Update #18
 

So, it seems like my hunch may have been wrong, it seems like the system is working much better now. I'm excited about this, but I'd still like more information. At the very least, it would be nice to know if all the discussion in this thread is valid, and I think it could be a great learning experience to show students how to design to a full specification. Plus, I personally think it's pretty impressive how two groups can collaborate with just specifications and at the end of the day their two separate solutions, developed in complete isolation, work together because they followed the agreed upon design specification.

Good luck teams, lets hope things continue to work well,
Matt

Re: Team Update #18
 

I didn't get to watch a ton of matches at Peachtree this weekend, but every minibot I saw that looked like it should have triggered the pole did so.

Re: Team Update #18
 

We just had a match yesterday where we launched our slower mini-bot (1.7 seconds). It clearly hit the top, but it apparently didn't trigger...

It was frustrating for that match to swing that way, it makes me empathetic for all of the teams who have these kinds of rulings which are out of their hands.

Re: Team Update #18
 

At St. Louis, one tower was hit twice with no response; they determined it was defective, switched it out, and fixed the previous scores. There were one or two other incidences of towers not registering hits, but they were borderline in terms of the amount of force applied. Overall the system seems to work OK.

Re: Team Update #18
 

I didn't really watch many webcasting this weekend, but from the bit of Bayou I saw, the referees were still using their judgement to call the minibot races. There were many false positives, though I only recall one instance of a minibot not triggering at the top.

Re: Team Update #18
 

So...local refs under the direction of local head refs disregard the update and deal with the reality of imperfect triggers? Let's hear it for common sense!

Re: Team Update #18
 

I love it!

Re: Team Update #18
 

Why bother having rules?

Re: Team Update #18
 

Wish they followed this path at Sacramento, we clearly hit the top with 1868's minibot (1.2 second climb) in our last finals match and the tower didn't trigger. Didn't change the match results, but I'm trying to imagine the outrage when a tower doesn't trigger on Einstein...

Re: Team Update #18
 

This is interesting as I never saw a single time at Sacramento where the towers missed a trigger. Now I must admit, I always focussed my attention on our minibot, so I might have missed yours. Ours is a bit of a tugboat, but it always triggers the tower, and even won several races.

By the way, you guys did a great job in Sacramento and deserved the win. Congratulations!

Re: Team Update #18
 

So, what's the objective of the minibot race, anyway? To trigger the tower first, or to reach the top first?*I know what the rules say, and that isn't it.

If the object of the race was to get there first, then sure, the referees would be totally right to award the race to the first minibot to arrive, irrespective of what the sensor did. But by defining the race in terms of the sensor, and then making an update to emphasize that point, FIRST has explicitly included the mechanical and electrical characteristics of the tower in the problem of winning the race.

Judging it based on sight—but only when the tower fails to trigger on what appeared to be a sufficient impact—fails to distinguish true negatives from false negatives. (Are the referees making the calls fully aware of the possibility and likelihood of a true negative?)

Incidentally, one could argue that the likelihood of a true negative is remote enough that they can all be disregarded—but I haven't seen that earnestly proposed, and frankly, if FIRST wanted that to be the case, they shouldn't have gone to all the effort to define the race in terms of the sensor. By taking pains to define it as they have, I think their thought process was that by removing human judgment from the outcome, they would have a lower rate of false outcomes than otherwise—but to achieve that accuracy, they had to make the sensor response a factor in the definition.

As for the "common sense" argument, I think our preconceptions about how a race is decided colour our opinions. It may well have been a better idea to conform to those expectations instead of crafting a rule that is slightly more complicated—but the rules are supposed to be the same for everyone, and by trying to correct this on a sporadic and unsystematic basis, I'm concerned that we're letting one element of equity infringe on another.

*Hints: <G67> and the definitions of trigger and minibot race. Why would they write that, but intend something else?

Re: Team Update #18
 

We have a decently fast minibot (~1.5 sec climb rate). It was 14/15 triggering the target at West Michigan. It triggered the sensors on all (4) towers throughout the weekend.

In SF1-1 we launched the minibot on the Red left side tower, it "won" the race but did not trigger the sensor. We were told that the ref saw that it hit first, but since we had won the match any way they were going to "trust the field".

I was not concerned about getting the actual score corrected, but more so about the next matches and how things would be scored if it didn't register again. We were told that the refs have the power to over rule the sensors if needed...but we were not specifically told that they would manually score our minibot if it didn't register again.

Our minibot never went up that tower again, but 2054's registered every time on that side.

This tower had the light knocked off it at one point on Friday and had not registered a couple other minibots at other times on Saturday.

We have a non-random pattern that our minibot is sufficiently designed to trigger the sensors. The field has a non-random pattern that their sensors are functioning correctly. There is some interaction between the tower and the minibot that in certain instances the variation in their performances line up to produce a false negative.

Is it FIRST, the team, or the refs responsibility to handle the < 5% chance that these variable line up and the sensors don't trigger?

We may attempt to make our minibot robust to this issue, but I am fine with leaving the instances where the match outcome would be effected in the hands of the refs...as long as the benefit of the doubt goes to the team.

Re: Team Update #18
 

Chris, I spoke with a team member of 308 after that match. He stated that the tower was disabled due to early deployment. Anyone from 308 can correct me on this if I am wrong.

Our towers triggered every time we successfully deployed at Detroit. Minibot ~2.5lbs or .025 Karthiks at ~ 1.2 - 1.6 seconds.

BTW it was great working with you Chris, I will save my additional comments for the detroit thread.

Re: Team Update #18
 

Many feel the problem is they did not also PROVIDE the mechanical and electrical characteristics of the tower. As far as I am aware the length of signal required to register with the FMS is still a mystery.

Re: Team Update #18
 

Which team? the team that failed to TRIGGER the TARGET, or the teams on the opposing alliance?

Come on now....

Re: Team Update #18
 

I was referring to the team that failed to trigger the target.

I would not want to win a match, District Championship, State Championship, or World Championship because my opposition built a minibot that was faster than mine, beat it up the pole, hit the target with the specified FORCE, but the sensors did not TRIGGER the target.

Especially if their minibot has an approaching 100% success rate and the failed TRIGGER is the result of some interation of unknown variables.

Seems to me checking to see if minibots trigger the target could be part of inspections. If you get the ok at inspections, then it is assumed that the minibot is designed correctly.

The refs would have the ultimate power to either believe or over rule the sensors. If a sensor does not trigger, but the team has passed minibot inspection (including triggering), the refs can determine the winner and assign the points accordingly. If it is too close to call, then the match will be replayed due to a field fault.

Its already bad enough that we spent 6 weeks designing a HOSTBOT that can achieve all the tasks of this game at a very high level, only to have it marginalized by a minibot that every team can build in one day.

Re: Team Update #18
 

I don't see an official definition of FORCE in the rules.

I would be fine winning a match because my opposition built a minibot that beat ours up the pole, but failed to TRIGGER the TARGET, which is what the rules require it to do. The rules do not make any exceptions.

I guess the thing to do is ask the head ref at our next regional whether they will be calling minibot races based on the rules, or something else.

Re: Team Update #18
 

I'm torn on this one.

On one hand, I believe the intent of the minibot race was to get their first (it's a race after all, it's displayed as such on the scoring metric) and I'm glad to see that refs stepped in when the technology couldn't.

But I'm also frustrated at the refs changing the rules again, while I don't agree with this team update, and I think it's a bad idea, if that's the rule, and that's what every team started working towards, it should be enforced as such. This particular dilemma is precisely why I thought it was a bad idea to throw all their weight behind the system like this, I don't think it's ready yet. Of course, we have no way of knowing if it's ready since we're still working on vague definitions of the 'black magic' actually required to trip the sensor. For all we know it's actually working 100% perfectly, but I suspect that isn't the case.

Matt

Re: Team Update #18
 

I talked to someone who should know at AZ, and I get the feeling that it is working 100%.

I'm also eagerly awaiting a Q&A response....

Re: Team Update #18
 

Okay, let's just bash at the base of the towers until it triggers. No need to actually race up the pole. So long as we're hitting the pole with our minibot, the minibot is pushing on the tower, which causes the tower to trigger, so it should count.

Fine with me.

I can guarantee you from watching the Bayou webcast, it is not working 100%. Not even close.