Interesting Q/A's

[Gary Bonner]

Best so far:

Q: Can we attach a motorcycle horn to our robot? If we can, are there any special considerations about when it can make noise or other paticular rules that would be esay to overlook with it?


A: A motorcycle horn is obnoxious and annoying. Any robot with such a device will be subjected to multiple 10 kV static discharges until it is writhing in robotic pain. It is also a violation of 7.13.2.

[KenWittlief]

A: A motorcycle horn is obnoxious and annoying. Any robot with such a device will be subjected to multiple 10 kV static discharges until it is writhing in robotic pain. It is also a violation of 7.13.2.

even as we speak the moral of an entire team somewhere has dropped through the floor! "There goes our entire strategy! Now we have to start over from scratch."

[Billfred]

And, a resolution to the shipping-the-robot-controller dealio (with a hint of explanation of FIRST's logic):

Q: While the RC is decidedly part of the robot, it is also required to download the programming that the rule is intended to allow. Since much of the software being used this season is too large for past years' controllers, the only way that comes to mind to have an RC to work on during the fix-it windows is to order a second RC, currently listed as "Call for availability" on IFI's website, for $450.

Additionally, IFI regards the RC as part of the FRC Control System (source: http://www.ifirobotics.com/frc-robo...-overview.shtml )

That said, would a naked, nothing-attached, just-as-you-first-saw-it-on-January-7 RC be permissible? If not, is there an alternative I've missed?

A: draft answer:

The IFI Robot Controller is considered part of the robot, and must be shipped with the robot prior to the shipping deadline.

The Fix-It-Windows are intended to permit teams to manufacture spare and replacement parts and develop software for their robot while at their home facility. Teams do not have direct access to the robot during these periods, and must rely on information they have generated during the design and build process to determine the fit and function of any parts developed during the Fix-It-Windows. In other words, documentation matters! This is true for both hardware and software.

There's still that imbalance of folks who can and can't purchase a second RC, but I guess we'll have to go back to the old saying that FIRST isn't fair.

[sanddrag]

I too have posted a question (in Section 5.3, but they may move it) on keeping the robot controller. It isn't up yet (I guess a mod needs to approve it) but the title will be "Purchasing an additional RC vs. keeping the KOP one" or something like that. I want a concrete response and a logical reason behind it. We'll see if we get it.

While on the forums, I found this one quite interesting: http://forums.usfirst.org/showthread.php?t=286

Q: Can we use the gear boxes from last year (2005) to encorprate in our ball thrower for the 2006 season?

A: Yes, provided they are not modified in any way.

I think they mean, "provided they were not modified before the 2006 kickoff event." They really need to be careful with their answers. I think the original rulebook is pretty good, and the team updates have been few and short, but the Q/A board answers I could see beginning to lead to some mass confusion and countless disputes.

[Tristan Lall]

Originally Posted by sanddrag

I think they mean, "provided they were not modified before the 2006 kickoff event."

To be absolutely pedantic, it should be "provided that they were neither modified, nor assembled, before the 2006 kickoff event". By <R15>, they can't re-use a mechanism, but they could probably get around it by putting it together in advance, taking it all apart, and re-assembling it during the season. (Functionally, it makes no difference, of course.)

[Rick TYler]

I'm going to go back to the FIRST Q&A forum on this, but I wanted to vent a little.

We are planning to use some slow-speed belts to move balls around inside the 'bot. In testing, we've been using some very fine (220 grit) previously used sanding belts for this. They work great and don't mar the balls. Now we're forced to go out and find something that will work as well (smooth on one side, grippy on the other), which will certainly cost a lot more and weigh more, to boot. I think they tossed out the baby with the bath water on this one.

1. I don't know why someone formally asked the question.

2. I really don't understand FIRST's blanket answer since FIRST already has a rule against mechanisms that damage balls. If a sanding belt conveyor isn't causing damage, why ban it?

Thank you. I don't really feel any better, but at least I've shared my pain.

[Madison]

Rick -- I presume you're talking about this response: http://forums.usfirst.org/showthread...ght=sand+paper

Did you also see this second, newer response? http://forums.usfirst.org/showthread...ght=sand+paper

It seems that the latter again allows sanding belt as a conveyance surface with the existing caveat that it must not damage balls.

[Rick TYler]

Madison, it's gotten ambiguous. This http://forums.usfirst.org/showthread...highlight=sand earlier thread specifically says, "It is reasonable to expect that sanding belts will damage the balls surfaces, even through incidental contact. As such, under the Parts Use Flowchart, sanding belts would not be permitted." I believe you could make this statement of any friction-based device for shooting or moving balls inside the robot. I know that our best shooting wheel (which meets velocity requirements and has a perfectly smooth surface) sometimes creates small marks on the surface of the balls. A strict interpretation of this rule would lead us to eliminate any friction-based mechanism. Good-bye wheel-based shooters.

[sanddrag]

I find this Q/A answer quite underwritten for such a thorough question.

http://forums.usfirst.org/showthread.php?t=442

Q:
My question pertains to sections 5.2, 5.3.3. and 6.3.5

In section 5 of the manual the definition of a FIX-IT-Window says
"During the FIX-IT WINDOWS, software for either the robot or operator interface may be developed without restriction."

The answer to a previous Q/A question (http://forums.usfirst.org/showthread.php?t=407) says "The Robot Controller is considered part of the robot, not part of the operator interface. As such, it must be shipped with the robot prior to the shipping deadline."

To me, this does not seem to be development "without restriction." Additionally, under <R17> and <R20> teams are allowed large amounts of time to develop software. So my questions are the following:

What use is the value in keeping the Operator Interface if we are required to ship the Robot Controller? Can a team purchase an additional robot controller to develop programming after the ship date? If yes, then why must teams incur this multi-hundred dollar cost to take advantage of the FIX-IT-WINDOWS as opposed to keeping (and not shipping) the one provided in the KOP? It seems like the previous Q/A is imposing an otherwise avoidable expense to teams who wish to program in the FIX-IT-WINDOWS Under-funded teams may be at a disadvantage.

Thanks.

A:
The IFI Robot Controller is considered part of the robot, and must be shipped with the robot prior to the shipping deadline.

The Fix-It-Windows are intended to permit teams to manufacture spare and replacement parts and develop software for their robot while at their home facility. Teams do not have direct access to the robot during these periods, and must rely on information they have generated during the design and build process to determine the fit and function of any parts developed during the Fix-It-Windows. This is true for both hardware and software.

Very disappointing. I feel I brought up some good points/arguments/questions only to have them ignored. This Q/A answer/ruling does nothing but channel money into IFI.

The answer to my other question here http://forums.usfirst.org/showthread.php?t=464 ins't so illogical but still disappointing.

[Nitroxextreme]

What I can't seem to understand is why this year is any different?

In the past teams were allowed to keep the RC and bring it with them to the first event. Last year we were forced to ship the RC out to IFI to get it repaired (under warranty ). If we were not allowed to bring it with us to the event we would have been forced to rely on shipping to get it there on time.

Being able to keep the RC gives teams the ability to be more realistic into the whole business plan idea. After a finished product is delivered the programmer will get time after the deadline to perfect the instructions(code).

[KenWittlief]

sounds like its time for someone to design an RC simultor, that runs on a PC, can simuate the function of the RC, and allow the user to define the inputs and outputs that are present on their robot?

That would allow SW to be tested with just the operators interface, and a PC.

[Tristan Lall]

This one bugs me a little, because of the reasonably elegant solution that the team has proposed, and the silly response that was received:

Originally Posted by FRC696

Consider we build a ball conveyor mechanism that is non-backdriveable and has no door . May we have additional leads coming out of the drive motor, so that when the match is over, the driver/operator can plug in a small 7.2V RC car battery to power the mechanism to quickly (<10 seconds) remove the balls? There would be no exposed wiring that would be cause for concern of a short. These additional leads on the motor would not be connected during the match. The RC car battery will always be kept charged and be kept with the driver and never installed on the robot.

Originally Posted by GDC

No. All motors/actuators on a FRC robot must be controlled through the Robot Controller.

Who hasn't connected a battery directly to a motor, to advance it, or to test it? The match is over, let the team do as they see fit—it's absolutely clear in the question that there is no possibility of the extra battery being used in a match, and it seems unlikely that the extra battery will hinder efforts to remove the robot from the field—indeed, it appears to do quite the opposite.

Of course, the best solution would be to design a system which doesn't need any extra power to release balls....

[Elgin Clock]

Question:
Rule <G27> states: "ROBOTs Must Throw the Balls into the Center Goal - Only a ROBOT may throw a ball into the center goal. The kinetic energy of the ball must be supplied by the ROBOT. A HUMAN PLAYER may not bounce a ball off a ROBOT and score it in the center goal. A violation of this rule will result in a 5-point penalty."

If the ball is scored by the human player does the automatic scoring system first score 3 points and then 5 points are taken off for a net of -2 points, or is the ball not counted and a 5 point penalty is assessed for a net of -5 points?

Answer:
In this case, the ball would be scored by the scoring system for 3 points, and then a 5-point penalty will be assessed, for a net -2 points.

OMG Amy, I love this one.. HA HA HA HA HA!!!!! That's great! Fun with numbers.

[meaubry]

I'm with Gary on this one - what the heck difference does it make if the 12 inch long pvc flag holder has little holes in it. The original rule didn't dis-allow that so why now???

[Rick TYler]

Two comments:

1. Use schedule 20 pipe -- it's lighter than Sched 40 or 80.

2. I wonder if a judge would really freak out if you built this with an ABS pipe instead? ABS is lighter and just as strong. It's not technically PVC, but then again, they already allowed 2.75-inch pool noodles, which are a clear violation of the written rules.

and a third for free:

3. Now that the robots have shipped, I hereby declare that FIRST Silly Season is officially open!