Announcement

Collapse
No announcement yet.

Dog gears for modular attachments

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

  • #76
    Re: Dog gears for modular attachments

    Originally posted by ratnip View Post
    My personal regret though is the fact that I was heavily emphasizing the "minimalistic approach" myself, not just because it was a necessity for us due to lack of parts, but also because I think one of the basic principles in engineering is "you don't use up 50 resources if you can do the same with 5". However, after getting the official judging results, I can't help but wonder if FLL as we experienced it leans towards "sure, you *may* use 5 resources if you wish, but 50 will get you extra points in the robot design category". :P
    Unnecessary complexity should not improve a teams ranking in Robot Design. If you look at the rubrics, there is a section for "Mechanical Efficiency - Economic use of parts and time; easy to repair and modify". If a team uses "excessive parts or time to repair/modify", they should be graded at the "Beginning" level. To earn an "Exemplary" grade, the team should have "streamlined use of parts and time to repair/modify".

    As a judge, I have given low scores in some sections of the rubrics to teams that used an excessive number of parts for what they accomplished. I've judged some teams that were far more interested in building crazy contraptions than they were in reliably solving the missions. It is certainly a reasonable approach if that's what the kids want to do. A team may end up with a high score in the Innovation section and low scores in Durability and Mechanical Efficiency.

    Comment


    • #77
      Re: Dog gears for modular attachments

      Originally posted by timdavid View Post
      Unnecessary complexity should not improve a teams ranking in Robot Design. If you look at the rubrics, there is a section for "Mechanical Efficiency - Economic use of parts and time; easy to repair and modify". If a team uses "excessive parts or time to repair/modify", they should be graded at the "Beginning" level. To earn an "Exemplary" grade, the team should have "streamlined use of parts and time to repair/modify".

      As a judge, I have given low scores in some sections of the rubrics to teams that used an excessive number of parts for what they accomplished. I've judged some teams that were far more interested in building crazy contraptions than they were in reliably solving the missions. It is certainly a reasonable approach if that's what the kids want to do. A team may end up with a high score in the Innovation section and low scores in Durability and Mechanical Efficiency.
      In all honesty, this is what irks me. we got the lowest scores across the board for our robot design, even though the robot was streamlined, durable, efficient and extremely consistent (we have the highest stability rate on the competition, achieving 90+ points on every run, out of our theoretical maximum of ~110). And yet, rock bottom for us.

      Comment


      • #78
        Re: Dog gears for modular attachments

        Originally posted by ratnip View Post
        In all honesty, this is what irks me. we got the lowest scores across the board for our robot design, even though the robot was streamlined, durable, efficient and extremely consistent (we have the highest stability rate on the competition, achieving 90+ points on every run, out of our theoretical maximum of ~110). And yet, rock bottom for us.
        I don't agree with the premise from the original post that the team had to design their entire robot from scratch. The rule is only that they have to do their own work, and give attribution to their sources. If they want to use an off-she-shelf base robot and focus on strategy, programming, and clever accessories, that's a totally legitimate method. Many very successful teams never get beyond that. Building from scratch is difficult. Teams who build those massive complex robots you see on the internet are a very small sample. Teams don't have to emulate that to be successful.

        Not every panel of judges is well-versed in what they're supposed to evaluate. It's just three folks who likely had minimal training, and then had to rank maybe 20 teams in rapid-succession and attempt to provide some useful feedback. It is a very difficult task, and the results can vary wildly from team to team and from event to event.

        How well the team communicates with the judge panel about their robot also has a big impact on their evaluation. The judge panel is hard-pressed, can be exhausted if they see your team at the end of the day. Sometimes the judges need a bit of help in recognizing a brilliantly simple design. Experienced teams know this. Rookie teams haven't learned it yet.

        Regarding the nature of the FLL games. Each year the game is designed to challenge teams that have a huge range of developmental ages, with team members of widely varying experience. It is unreasonable to assume that a team of rookies starting from scratch are going to out-robot a team with loads of experience. But hopefully they have a good enough experience that they come back for the next year's challenge.
        FIRST Tech Challenge Judge: 2010, Referee: 2017
        FIRST LEGO League Mentor, Instructor, and/or Referee/Head Referee since 2011
        FIRST Robotics Competition judge (Chairman's Award): 2014
        Dean says I'm an "Oompa Loompa of Science"

        Comment


        • #79
          Re: Dog gears for modular attachments

          Originally posted by Tom Mosher View Post
          I don't agree with the premise ...
          +1 to Tom's remarks. In recognition of his 2001st post, I'm listening to Also Sprach Zarathustra as I type these remarks.

          I'll echo that robot judging can be subjective and variable. If your kids were excited about the monster robots they saw at the tournament, by all means, go ahead and use that approach for next season. But don't feel compelled to follow that approach just to improve your robot judging score. There are plenty of judges that understand the KISS principle. Just make sure the kids elaborate on the benefits of simple approaches when they talk to the judges.

          Comment


          • #80
            Re: Dog gears for modular attachments

            Maybe 1/2 the robots I see are the robot educator design or a really close relative. When judging those teams I mostly ignore the robot and look at the attachments. My "Mechanization" and "Durability" scores don't vary much, most FLL robots are adequate delivery trucks for their attachments. "Mechanical Efficiency" is a bit more interesting. I see some teams that do a lot with very little, and others that do very little with quite a lot.

            The interesting categories are "Automation/Navigation", "Mission Strategy" and "Design Process". Here is where you can stand apart from the crowd. For Automation/Navigation you should try to avoid aiming as much as possible. Have the robot do most of the work. If there is room for operator error your solution needs more work. If your solution works because you are lucky your solution needs more work. A good solution is difficult to mess up. A good solution works even when the operator messes up or you have a minor disaster.

            For Mission Strategy it is really important to have an overall plan. Most teams do the missions they can solve. That is not a plan. Other teams execute the missions in the order they were solved. That is not a plan. To get big points in Mission Strategy you need to stop thinking about missions and start thinking about a solution. How does getting the bee relate to putting in on the hive? How do these relate to collecting food? How does this relate to dispensing food? How does that relate to the conservation model, or the milking model or the wall. There should be a reason behind your solutions and their order. Know what that is and discuss it with the judges.

            Design process is my favorite, and it is tightly tied to mission strategy. Without a mission strategy you design process is limited to finding solutions to the various missions. You can get a Developing or maybe even Accomplished grade for solving missions, but to be Exemplary you need to design a complete solution. There needs to be a reason for everything you do, and the reason behind how you solved the shark tank should have something to do with how you solved the milking mission. Be ready to tell the judges how all the parts of your solution work together to make an efficient game solution. Forgetting to do this or being unable to do this is the most common failing I see in teams. I see a lot of teams that build great robots and fantastic solutions but nothing really fits together. They spent all their time solving missions and building stuff and forgot to spend any time making all the parts work smoothly together.
            Last edited by Dean Hystad; 02-15-2017, 09:21 PM.

            Comment


            • #81
              Re: Dog gears for modular attachments

              Originally posted by Tom Mosher View Post
              How well the team communicates with the judge panel about their robot also has a big impact on their evaluation. The judge panel is hard-pressed, can be exhausted if they see your team at the end of the day. Sometimes the judges need a bit of help in recognizing a brilliantly simple design. Experienced teams know this. Rookie teams haven't learned it yet.
              When I start the judging session I tell teams that they have to tell me about anything cool their robot does because I can't read minds. They begin demonstrating the robot and during the mission the robot uses a sensor and the team remains silent. I ask why the robot did that little wiggle or why it slowed down or stopped there and when they tell me the light sensor was looking for a line I say "That is one of those things I asked you to point out. I'll give you a free pass this time." After the third free pass I might say "You're killin me Small's (because I like "The Sandlot" and most FLLers are small). Why don't you want to tell me about sensor use or how that attachment works or how you came up with the idea to solve the mission this way? I'm getting tired of being so observant and I'm afraid I'm going to start missing things."

              Good judges work with the team to squeeze out every last drop bit of information, but it the team's job to inform the judge, not the judge's job to interrogate the team. If you don't do your job don't expect a good evaluation.

              Comment


              • #82
                Re: Dog gears for modular attachments

                Originally posted by Dean Hystad View Post
                For Mission Strategy it is really important to have an overall plan. Most teams do the missions they can solve. That is not a plan. Other teams execute the missions in the order they were solved. That is not a plan. To get big points in Mission Strategy you need to stop thinking about missions and start thinking about a solution. How does getting the bee relate to putting in on the hive? How do these relate to collecting food? How does this relate to dispensing food? How does that relate to the conservation model, or the milking model or the wall. There should be a reason behind your solutions and their order. Know what that is and discuss it with the judges.
                Does anyone have any ideas on how to help the kids, particularly younger kids, understand this?

                It's something that I've struggled with in my years coaching. As an engineer, I see an overall game and, if I were designing a solution, I would start by coming up with an overall plan, categorizing the missions by location on the board, type of movement/mechanism required to solve them, perceived difficulty, point value, time required, etc. Then by grouping the missions different ways, I'd develop a strategy for solving the missions, come up with specifications for my robot and attachments, build a robot, build the attachments and then begin an iterative process of testing and modification of my robot, attachments and programs to solve the missions according to the plan.
                However, almost all the members of my teams seem to think like golden retriever puppies (cute, cuddly, attention span of 18 seconds on a good day) - "Legos! Woo-hoo!" and jump right into their favorite part of the Robot Game (building attachments or programming, etc) without taking the time to think things through. The strategy seems to come later then they realize that their cool solution for getting the bee on the hive just isn't going to work without drastically changing the robot which will completely screw up the missions that their teammates almost have working and, oh yeah, the mission to feed those two animals needs to also get that pesky manure sample out of the way so it's easier to navigate after coming over the seeing eye dog barrier, so I guess that one needs to be done before the dog mission...

                TL/DR - How can I help my kids think strategically about the Robot Game rather than just jumping in to do what looks cool?
                --
                Fort Worth Robotics - North Texas Region Team #455
                Technical coach, baker of the cookies, keeper of the time, transporter of the travel field walls, finder of the spare parts, maker of the pop culture references that only the other tall people understand.

                Comment


                • #83
                  Re: Dog gears for modular attachments

                  Originally posted by gt0163c View Post
                  TL/DR - How can I help my kids think strategically about the Robot Game rather than just jumping in to do what looks cool?
                  I don't know if this is something you need to do. Personally I really like it when the team jumps in and works on what looks cool. They are excited and having fun and doing exactly what I want them to do. After a while the missions start looking less interesting and the desire to jump in and do what looks cool fades. That's when I have them start thinking about the missions as parts of a game and developing strategies for winning the game. I use their competitive urges to keep their interest.

                  Comment


                  • #84
                    Re: Dog gears for modular attachments

                    Originally posted by gt0163c View Post
                    However, almost all the members of my teams seem to think like golden retriever puppies (cute, cuddly, attention span of 18 seconds on a good day) - "Legos! Woo-hoo!" and jump right into their favorite part of the Robot Game (building attachments or programming, etc) without taking the time to think things through.

                    I struggled with this too, being my first year and whatnot. The kids just randomly chose a mission they thought looked fun, and then started programming block by block, immediately testing it on the field. This soon became horribly chaotic and tiresome, not to mention not the least productive.

                    So my course of action on the next meeting was - take out from the equation the field, the robot, the laptops, basically everything fun.

                    Every team member got a challenge guide and a few papers with the top view of the field printed on it. I asked the kids then to go mission by mission, and precisely sketch what they think the robot should do, step by step, using lines on the paper, numbers for individual steps. and brief text descriptions for what they think the robot should be doing at which point. After that they were required to choose a few of their sketches and write the code in plaintext, as detailed as possible (e.g. 1) Robot goes forward to reach point A, 2) Robot turns 90 degrees to the left etc.). Only after we got this papery preparation done they were allowed to actually start building the attachments, programming etc.

                    I don't know whether this is a recommended approach and I'm pretty sure the expert teams use a much more advanced systematic method, but this turned out rather fine for us. Even though there was much grumbling at first, the kids really appreciated having those mission sketches and outlines once the actual programming started. I also loved seeing how they actually used the text from the papers to insert comments in the programs (for cross-reference), so they ended up with these incredibly densely documented programs. I plan to use the similar approach next year - unless I manage to figure out a better way, based on suggestions of expert coaches here.

                    Comment


                    • #85
                      Re: Dog gears for modular attachments

                      The 'sketch it out' method is a great way to get them thinking sequentially about the problem, and keep the sketches to show the judges for process! One thing I try to teach my team is that there are many things you can do to introduce error in the program, and the farther you go without using sensors to orient your robot the more position error is going to happen. (usually light/color, but we use the gyro for some things as well. I think we may have to attempt the ultrasonic next year)

                      Another thing we started doing was keeping a log/ spreadsheet with estimated mission time with points achieved by that mission. That way, if a low scoring mission is getting in the way of the points from a high scoring mission, we can identify it quickly. As the kids and coach get more experience, you can add implementation time to the calculation as well. It's going to seem like a lot of process, but when we swapped out the pig mission with delivering six food, the score shot up (even if half the food doesn't make it in the circle)
                      Coach, FLL Team 3146 Peace By Piece 2013 - 2016; Team 29410 The Dragon Bots 2016
                      Judge, FTC 2014-2015; Field Technical Advisor, FTC 2016

                      Comment


                      • #86
                        Re: Dog gears for modular attachments

                        Programs shouldn't be built block by block, but I am a big proponent of early testing and testing the smallest testable parts. I think sketching out entire missions early in the development cycle is a bad idea.

                        The main problem with most team's development cycle is they start thinking about sequence too early. They build an attachment to get food from the refrigerator and to test they write a program that drives out of base, navigates over to the refrigerator, tries to get food, returns to base. They test using missions. Program development should start at the refrigerator. Your first testing can probably be performed without the robot. After you get an attachment that looks like it should work your early test programs should do nothing but move the attachment. Once you get the attachment working well you have your first my block. Now you can write a little stub program that drives the robot a few inches and runs the attachment my block. You can play around manually positioning the robot to see how tolerant your attachment is of positioning error. Once you have the stub program running and you are happy with the results it is time to move on the next attachment. Once you have multiple attachments working you can start thinking about how the robot is going to start in base and move from model to model.

                        The beauty of this approach is you separate interacting with models from navigation. If a mission stops working you can run the stub program to see if it is an attachment error or a navigation error. If it is a navigation error you can use the stub program to find out how much navigation error you can tolerate. If a small amount of navigation error causes the mission to fail you can use the stub to test any attempts to make the attachment more robust. Once you are happy with the modified attachment you know how much navigation error can be tolerated and this helps you when writing the navigation parts of your program.

                        Another advantage is that you don't create any missions until you have multiple attachments working. There is very little ownership other than attachment design. Spending lots of time writing code to get the robot to the model and back to base results in the team being resistant to any changes in how the robot interacts with the models. They spent a lot of time and they had something that scored points. That is difficult to give up. Stopping development as soon as the attachment works minimizes the time spent on any model and there are no points given up if you change your mind on how to solve a mission. It will be easier to convince the conservation model attachment design team to change their design to integrate with the food delivery design and the service dog design team to make a mission that lowers the gate, delivers food and spins the conservation model.

                        Experienced teams can do top-down planning. My daughter came up with a very good solution while looking over my shoulder as I read the Trash Trek rules. Rookie teams cannot do this because they have no idea how to solve any mission, no idea what missions can be combined, and no idea how combining missions can save time. This only comes with experience. Eventually they will see that missions A, B and C can be solved using a stick and missions D, E and F require a box. Then you can think about compatible boxes that work for A, B and C, and compatible sticks that work for D, E and F. You might even come up with a box/stick combination that works for them all, then you can combine missions based on geography. But none of this can be done early on. First your team needs to solve missions. Don't try to develop a comprehensive plan until you know the pieces you have to work with. There is noting wrong working from the bottom up, just don't spend so much time working on the foundation pieces that you have no time left for integration.
                        Last edited by Dean Hystad; 02-16-2017, 12:42 PM.

                        Comment


                        • #87
                          Re: Dog gears for modular attachments

                          Originally posted by Dean Hystad View Post
                          Programs shouldn't be built block by block, but I am a big proponent of early testing and testing the smallest testable parts. I think sketching out entire missions early in the development cycle is a bad idea.
                          I agree that testing the smallest testable parts is a great idea. However the kids in my team didn't initially think of programs as a collection of "testable parts", as in logical groupings of certain subroutines with a specific function. They thought of them as a bunch of blocks lined one after another. So they would literally create a "move forward" block, test it out on the field, then guesstimated the next step, program it in, then the next, then the next etc. Half the time they would forget what they were initially trying to do, while the other half they got frustrated because the robot seemingly changed behavior (not surprising of course, since they weren't exactly precise with the starting position).

                          Sketching out the missions as a whole was a way to stop this utter chaos. Later on, when things smoothed up a bit and when we got as far as to actually introduce MyBlocks, testing individual parts was a huge part of the mission construction. But that initial days of mission solving were hectic madness, and the sketches helped immensely to break away from the "block by block" mentality which was everything but productive.

                          Comment


                          • #88
                            Re: Dog gears for modular attachments

                            You don't need to think of programs as testable parts. For my girls a testable part was and idea for an attachment. They would knock something together to see if the idea was worth pursuing. Initial testing is done using hands instead of robot. If the idea looked good they built a better prototype that can attach to the robot. My girls did a lot of testing using a robot stand-in. It had the same attachment points as the robot, but no motors or sensors. If the idea still looked good they would write a tiny program to move the attachment. If the attachment worked well they would convert the code to a my block and write a test program that preceded the my block with a short move so they could test how sensitive the attachment was to navigation errors.

                            Each of these steps is a testable part. The longest program is only a few blocks. If you have a tablet or phone you can write the test program using that to free up the laptop. The team I worked with this year followed this sequence for their conservation mission. They tried different attachments for pumping the conservation model lever. After trying several different pumpers they attached the best to the robot and wrote a small program to raise and lower the attachment. They played with different power settings and timing to get an efficient pumping action. When they got the performance they wanted the program was converted into a my block. The entire thing was 3 blocks inside a loop. Never did it occur to them that they were doing unit testing. They were just getting the pumper to work well before they used it in a mission. After doing this a few times they saw the value of writing small chunks of code that performed a well defined task. Every team can adopt that mentality.
                            Last edited by Dean Hystad; 02-16-2017, 06:58 PM.

                            Comment


                            • #89
                              Re: Dog gears for modular attachments

                              We are still kinda struggling with active attachments, so our "testable" parts were mostly concerned with making the robot end up where we wish for him to end up. A significant part of the struggle was making children realize that you do not necessarily need to build a robot which is incredibly precise, you need to build one which can be imprecise and still succeed in the mission. A lot of them had experience with Scratch and Logo and they were used to the principle that the program will run identically every time, so the erratic behavior of the robot frustrated them to no end (but it just did it correctly! why is it not working correctly anymore?). One of my favorite parts of preparation was seeing one kid get try to make the robot stand a specific length from the wall, and never getting it right - only to realize that he could make the robot run forward to the wall, and then go back the specific amount. I understand that this is one of the most basic FLL "tricks" you can use, but it worked as a huge revelation for the team.

                              This year we are definitely diving into active modules a bit more. Which is why I'm definitely interested in this dog gear attachments - they seem like a cool starting point. (see how I elegantly looped back to the thread subject? :P)

                              Comment


                              • #90
                                Re: Dog gears for modular attachments

                                Originally posted by ratnip View Post
                                One of my favorite parts of preparation was seeing one kid get try to make the robot stand a specific length from the wall, and never getting it right - only to realize that he could make the robot run forward to the wall, and then go back the specific amount. I understand that this is one of the most basic FLL "tricks" you can use, but it worked as a huge revelation for the team.
                                Basic,common, fundamental or not, it is a HUGE accomplishment to come up with it themselves. Every bit as fantastic a discovery as the first team that thought up the idea.

                                As far as "testable" goes, even passive attachments should get test stubs. Pushing the pink pet to the farm probably doesn't require a test stub, but pushing the bar on the refrigerator would benefit from localized testing. The same holds true for the milking mission. If you start from base and the mission fails because you don't release the lock pins is it a navigation issue or is it a mechanical issue. Writing a small program that only does the last 1 or 2 moves of the path from base will let you test this without hogging the base, without having to worry about the preceding 5 moves, and without worrying about if you set the thing up correctly for the start of the mission.

                                Dog gears provide a way to deliver power to complicated attachments. They work well with the "shell" design paradigm. They aren't particularly well suited for a simple arm. One of the teams I worked with this year built a dog-gear attachment for the robot educator design. It essentially made that motor worthless because they were unable to design mechanisms to transfer the motor power into useful motion. Once the dog gear came off they were able to design multiple attachments that all used the same simple connections. If I was just starting to work on active attachments I would start with something simpler and more immediate than dog gears. It all depends on how comfortable your team is with mechanical design.
                                Last edited by Dean Hystad; 02-17-2017, 02:11 PM.

                                Comment

                                Working...
                                X