No announcement yet.

Starting Robot Design for Rookie Team and Rookie Coach

  • Filter
  • Time
  • Show
Clear All
new posts

  • Starting Robot Design for Rookie Team and Rookie Coach


    Bottom Line Up Front: How capable of a robot design should we use to start?

    Our practices won't begin until late September. I'm curious about people's thoughts on how I should approach robot design. I want the team to revise their design as they learn more. My main question is with regards to the starting design.

    I'm worried that the basic design will require more improvement than we have time for. I like the idea of starting with a more capable design, but I don't want it so good that the kids don't improve it all.

    I would appreciate any advice on this.

    Thank you

  • #2
    Start with the robot educator design. Build instructions come with the edu software, it is a fairly easy build and you will have a robot after your first meeting. It is capable of solving every mission, except perhaps climbing the bridge, but it has enough flaws that you'll want to make some mods after working with it for a while.

    The last thing you want is to spend a lot of time choosing or designing a robot when you don't know enough to choose or design a robot. The worst thing you can do is copy a good robot. You'll never learn why it is good and you'll never be able to design your own.

    I am of the opinion that rhe robot matters very little. I see lots of crummy robots do well because the team's solution demands very little of the robot. I've also seen many great robots score really low because the team hadn't learned enough about robots to design good solutions.
    Last edited by Dean Hystad; 09-08-2019, 06:54 PM.


    • #3
      As a robot design judge, I like to see teams start with a simple design and improve it over time. Teams that start with a more capable design usually are not able to explain the design choices for the robot because they didn't make any of the choices. Teams should be able to explain their "Design Process" in the robot design judging.

      Ability to develop and explain improvement cycles where alternatives are considered and narrowed, selections tested, designs improved

      Let the kids make some choices, learn and enjoy the process. Most rookie teams don't end up with world class robots, and that's OK.
      Last edited by timdavid; 09-10-2019, 09:17 AM.


      • #4
        I've kept track of robot designs in my region for several years. Last year was pretty typical -- 63.7% of the robots were based on the robot design from the kit, and 40.2% were kitbots that weren't modified except for adding attachments. A higher percentage of robots that qualified for our Regional Championships were custom, but not much higher -- 56.5% of the Champs robots were based on the kit instructions, and 26.1% were the unmodified kitbot. Most of the modifications were minimal -- different wheels, adding side rails, replacing the rear ball caster, etc.

        I'm of the opinion that an inexperienced team spending a lot of time trying to build the perfect robot isn't likely to produce a good robot. I agree with Dean -- much better to start simple & modify as needed; one major benefit is being able to get started quickly. Some of the simple robots I've seen have great strategy & programming and do well; many of the complex robots look really cool but just don't work.
        Last edited by someonewhobikes; 09-09-2019, 12:15 AM. Reason: Hopefully cleared up some wording issues.
        Kansas City Region Head Ref 2014-present
        KC Region coaches and teams can ask FLL robot game rules questions at [email protected]


        • #5
          Come to think of it, I am of the opinion that a really good robot is more bane than boon. If the robot is a little lacking you learn right away that the solution must compensate for imperfections. If you are unfortunate enough to have a robot that drives straight and turns well you may not learn that lesson until you run your robot on different tables at the tournament. That a poor performing robot may result in a better game solution has got to be one of the most counter intuitive you've ever heard. However, based on what I observe working with teams and talking to teams at tournaments I believe it to be true. When the robot works well, teams are lulled into thinking the solution is robust, when it is more likely that the robot is just repeatable. Repeatability is not the same as robustness, and of the two, robustness is far more important to getting a good score.

          A repeatable robot will do the same thing every time, even when the same thing is the wrong thing. One year my daughter's team had a very repeatable robot. Starting about a month before the tournament their solution never failed to work, not once in maybe a hundred or so runs. They even tried some stress testing, starting the robot in different locations, setting up the attachments wrong, shining bright lights at the light sensors, placing books under the corners of the table, making bumps on the table walls and placing coins under the mat to make bumps. The robot passed all tests with aplomb. They were certain their solution accounted for all possible failure modes and FLL was about to see the first perfect robot. At the tournament they tested the robot on all the practice tables and it worked perfectly each time. They were confident starting the robot for the first table run, and the robot failed. Afterwards they ran the mission on all the practice tables, and it worked flawlessly. Thinking run 1 was a fluke, they were still confident starting the robot for table run 2, and it failed again. Having plenty of time they ran the mission a second time, watching very carefully for where it failed. For some reason one of the turns was a little off, but they could see no reason why. Again the robot worked perfectly when tested on the practice tables and they did not have enough data to make any changes. Table run 3 was on a different table, and the solution worked flawlessly. There was one cursed table at the tournament, and that was the table for most of their runs that day. After the tournament the girls added an ultrasonic sensor to measure distance to the north wall after making the critical turn. They tested the fix by bumping the robot or placing loose pieces of paper in the robot's path. They had no idea what was happening on that one table, so all they could do is try to replicate the failure and see if their fix could identify and correct. The sensor and accompanying logic identified bad turns and made appropriate corrections, and the robot never failed to make that turn again. If the girl's robot had been less repeatable they would have identified the weakness in their solution earlier and come up with the ultrasonic sensor fix before the tournament instead of after. The sensor worked better than a repeatable robot because the repeatable robot could not recover from an unexpected change in the environment.

          Give up on the idea of trying to control everything. Things will happen at the tournament that never happened on your practice table. If you try to make missions reliable by making the robot operation repeatable those unexpected things are going to make your missions fail. Lots of teams spend way too much time building jigs to make the robot start at the same location every time, or creating rituals about how the robot is set up before each run. I remember when the hot topics on this forum were about finding matching motors so the robot didn't jerk at the start of a move, or doing a "battery burn down" because the robot behaved differently with fully charged batteries than it did after a couple of missions. It was a common belief that if you controlled all the variables that the missions would work every time. That may be true, but there is no way you can control all the variables. I think the pendulum has swayed, and I am seeing more "smart" solutions that use sensors and mechanical alignment to identify and correct for navigation errors, and solutions that accommodate a lot of positioning error.
          Last edited by Dean Hystad; 09-09-2019, 05:10 PM.


          • #6

            Thank you for very much for your thoughtful comments. We will start with the basic robot and go from there.

            Thank you!