Announcement

Collapse
No announcement yet.

Clarification on R13: Launching

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Clarification on R13: Launching

    Our team's robot has an arm connected to a large motor at the front. This arm carries the tripod across the field to the appropriate circle and deposits it. It then goes and gets the yellow pipe in order to complete the pipe removal mission.

    In order for the arm to be at the right place at the right times, my team wants to start with the arm on the floor in base.

    Question: Given R13, can the robot operator press the start button on the robot, and then, while the program executes a 3 second wait block and lifts the arm, position the tripod on the lifted arm? All of this happens fully inside base, and then after the 3 second pause, the robot proceeds out of base to position the tripod.

    Basically, is it legal to touch the robot after pressing the start button while still fully in base, or does pressing the start button constitute the start of the run?

    Thanks in advance for your help.

  • #2
    You cannot touch the robot or anything the robot is touching after launch. As soon as you do the robot is interrupted and you need to launch again. However, pressing a button to start the program is not a launch. The rules say you have to press a button or signal a sensor to do a launch. It doesn't say what button or what sensors. Waiting for a timer to elapse is not signalling a sensor, so that shouldn't be accepted as a launch action, but you could replace the timed wait with a wait for button press. So you would start the program, load the tripod, and press the button again (or another button) to perform the launch.
    Last edited by Dean Hystad; 10-12-2017, 10:27 PM.

    Comment


    • #3
      Thank you!

      Comment


      • #4
        Any touch is an interruption, regardless of where the robot is located. Any interruption makes the robot not autonomous and the only way to make an autonomous robot is thru another valid "launch". The location of the robot at the point of interruption is only used to determine if a penalty is assessed.

        I may not have grasped the team's planned technique, but there is nothing to prevent a team from "starting" program A that somehow positions or reset motors, etc. Then interrupt the bot by placing on the tripod or other manipulations. Then "starting" program B which is the "launch". In other words separate the elements into smaller sections.

        Just so that nothing is moving and nothing is being touched, in the mere moments just before the "launch". What happens in base before the launch, is fairly open.


        No different from teams that accidently run program G when they intended to run program H. They grab (interrupt) the bot before it can exit base. They setup again fresh and launch, no penalty.

        Comment


        • #5
          I disagree. A touch is an interruption only if it occurs after a launch. From the challenge guide:

          D09 - INTERRUPTION - The next time you interact with the Robot after Launching it, that's an "Interruption."
          D08 - LAUNCH - Whenever you're done handling the robot and then you make it GO, that's a "Launch."

          The OP asks if it is ok to start the program, interact with the robot, and then launch by waiting for time. This is not a proper launch because later on the procedure for a launch says:

          "Reach down and touch a button or signal a sensor to activate a program."

          Waiting for a timer to expire is not touching a button or signaling a sensor. The robot is not launched and it cannot drive out an interact with models.

          Changing the procedure to wait for a button or touch sensor press (I see this a lot) is a valid launch. Now the team can start a program, interact with the robot in base, and then launch when they are ready. Any interaction with the robot prior to the second button press is not an interruption because it didn't occur after a launch.
          Last edited by Dean Hystad; 10-13-2017, 03:55 PM.

          Comment


          • #6
            I think Dean is right on this one.

            dna1990 in your second paragraph you talk about program A and program B, but my team only has program A with a 3 second wait block as the second block in the program. Dean's solution of changing that wait (for seconds) block to a wait (for button press) block is spot on it seems to me.

            Comment


            • #7
              OK you can't interrupt a non-autonomous bot. That is correct. My statement left that assumed (bad). My point was trying to emphasize (mostly for other readers) that base location didn't make or not make an interruption. It only defines if it penalized.

              And so that was also trying to point out that no, you can't launch a bot and later touch/interrupt it, regardless if the bot was running a timer, or other code, or anything. Or was still in base or not.

              And yes, a single program can certainly be made to eventually "wait" on a button or sensor event, thus defining a launch "window" for the technician. Even if that program does some other "stuff" before that point, while in base - like pre-position motors, make beeps, display things, or whatever.


              So I think everyone was saying yes - the team can accomplish what they want (move some motors while in base, hand position some mission models, then have a legit launch), but the process has to be broken apart and not just held together with a timed wait.



              I think in World Class, there was lots of discussions about that season's rule text and the mission where you had to "re-launch" between attempts at that clockwork type mission model. Teams would just put bot in a loop move forward, move backward, wait X time - repeat. And for a long time, timers were being advocated as "sensors". However in the end, at least by the time WF rolled around - refs were insistent that teams "activate" the bot via more physical sensor or button. I think the current R13 text (as stated by Dean) helps further clarify and disallow any arguments of using timers as launch separators.

              Comment


              • #8
                If I am interpreting what the OP wrote correctly, the operator presses the start button. During the next 3 seconds, the Robot lifts the arm and the operator places the Tripod onto the arm. At the end of the 3 second period, the Robot then starts driving out of Base.

                Aside from the legality of what your team is proposing to do, they should also think about how reliably they can properly place the Tripod onto the arm in less than 3 seconds, before the Robot stats driving out of Base. Perhaps they can try this 10 times in succession to see what their rate of success is.

                Comment


                • #9
                  Originally posted by philso View Post
                  If I am interpreting what the OP wrote correctly, the operator presses the start button. During the next 3 seconds, the Robot lifts the arm and the operator places the Tripod onto the arm. At the end of the 3 second period, the Robot then starts driving out of Base.
                  If this is an accurate summary, then pressing the start button is a Launch , and "placing the Tripod on the arm" is "interacting with the robot", and therefore an Interruption.
                  The only thing the team can do with an Interrupted rob t is re-Launch it. That requires "touching a button or signaling a sensor".

                  So I don't think waiting for the 3-second period to expire results in a legal Launch.
                  FIRST LEGO League Mentor and Referee/Head Referee since 2011.

                  Comment

                  Working...
                  X