Taking Robot out of Bag

[Sparkyshires]

Originally Posted by Michael Hill

I'm inclined to agree with this. I do question software though. If you bagged your robot with no code on it, but have been working on a separate robot, can you download the code you've been working on so you can drive/demo?

I would be inclined to say yes, but you only have one shot to make it work. No troubleshooting the code. Because you can work on the code while its in the bag, I don't think its an issue. However, it is a slightly gray area. I would say if any teams try out new code, be sure to not print out any diagnostics, don't check the driverstation screen, and if it doesn't work first try just shut it down. that way, there's no chance of "working on it". And if you wanna be extra paranoid, make sure you undeploy the code after you finish.

[Mark McLeod]

I'd think that new code and driving means we are modifying the bagged components and testing the changes.

I wouldn't put anything new onto the bagged portion of the robot, be it code or a mechanism.
Just a battery to drive with whatever code and mechanisms we bagged it with.

We were suppose to bag it in proper condition to demo it.
Not work on it later to make it demo'able.
Of course we prepared by bagging ours with drivable code, and I have sympathy for the programmers who aren't given any time on the robot before bagging...
It's the mechanical guys who hogged the robot before bagging that I don't have any sympathy for.


P.S.
I suppose bumpers that were already mounted pre-bagging and haven't been subsequently modified might be okay to drop on.
Just because they aren't baggable components.
But if they've never been mounted then I wouldn't put them on until the robot gets unbagged for official work.

[FrankJ]

As a mechanical guy, we have a policy to give the robot to the coders on day 1 & not start the mechanical until the coders are done.

[jvriezen]

Make lemons out of lemonade...

Its clear that you can take whats in the bag out and have a static display (no driving by competition drivers) for 4 hours. Leave the bot sitting on the bag, or the bag next to the bot by your display, and it will invite questions. This will give you an opportunity to talk about other key aspects of FRC, regarding how it is a mini version of a real world engineering project, with real world deadlines and contingency plans that involve working hard to make the bot complete at the competition.

Then, use lots of videos with a big monitor to show your best bots in action (unless you are a rookie team.. then show video of someone else's bot!)

[Mark McLeod]

Originally Posted by FrankJ

As a mechanical guy, we have a policy to give the robot to the coders on day 1 & not start the mechanical until the coders are done.

Then the code by definition works perfectly until you mechanical guys mess it up by adding your mechanisms

[Jon Stratis]

Originally Posted by Billfred

I went ahead and asked this question on Q&A, in the hopes of clearing the air:

And the GDC hath spoken:

Q. Regarding Section 5.4.3: We withheld a significant mechanism on our robot. Without this bolts-and-two-wires mechanism, our robot is far less demo-able. Is it "working on" if we unbag, bolt the withheld parts into existing holes to demo, unbolt, and bag a Clearly Completely Un-Worked-On Robot?

A. Yes, this would be considered working on the ROBOT.

https://frc-qa.usfirst.org/Question/...olt-the-withhe

[Ginger Power]

Originally Posted by Jon Stratis

And the GDC hath spoken:


https://frc-qa.usfirst.org/Question/...olt-the-withhe

I stand corrected thanks for the clarification!

[eli2410]

I would suggest that if you plan to take it out under the robot display rule and doing anything with it while you have it unbagged, you email someone at FIRST your EXACT plans of what you want to do, to make sure it is ok. Don't do anything until they have approved every single part of it. That way, if they come back and say that something you did was illegal, you have a record saying exactly what you did and that someone at FIRST told you it was ok to do your display. Keeps you safe when you are doing things that may be in or close to the grey area.

[Pault]

I find the problem of new code very interesting. On one hand, you are most definitely gaining an advantage if you realize your code doesn't work. I don't care if you didn't do any diagnostics at all, or if you didn't try to fix it and redeploy, you now know that your code does this thing that you don't want it to do, and many times that alone is enough for you to figure out how to fix it.

On the other hand, many teams don't have version control. What if a team doesn't have the version of their code from when the robot was unbagged available? Are they just not allowed to deploy code to their robot? That would really hurt the demo.

I'm going to lean towards no: you can't deploy new code. Sure, it may mean that some teams can't take full advantage of this rule, but it is not much different than temporarily mounting components. FIRST gave us this wonderful oppurtunity, let's not push it.

That being said, Q&A is probably, once again, the proper route on this one.

[Billfred]

Originally Posted by Jon Stratis

And the GDC hath spoken:


https://frc-qa.usfirst.org/Question/...olt-the-withhe

This answer doesn't shock me. I think there are ways* to improve the rule to make for better displays without creating a competitive advantage (especially in a big-withholding year), but we'll abide by the ruling.

*My suggestion/ideal scenario: No fabrication while unbagged, parts and assemblies may go on and code may be downloaded. All must be restored to as-unbagged condition before bagging.