Page 9 of 9 FirstFirst ... 56789
Results 81 to 90 of 90

Thread: Dog gears for modular attachments

  1. #81
    Join Date
    Sep 2008
    Location
    Eden Prairie, Minnesota
    Posts
    4,170

    Default Re: Dog gears for modular attachments

    Quote 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.

  2. #82
    Join Date
    Aug 2014
    Location
    North Texas
    Posts
    89

    Default Re: Dog gears for modular attachments

    Quote 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.

  3. #83
    Join Date
    Sep 2008
    Location
    Eden Prairie, Minnesota
    Posts
    4,170

    Default Re: Dog gears for modular attachments

    Quote 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.

  4. #84
    Join Date
    Sep 2016
    Posts
    6

    Default Re: Dog gears for modular attachments

    Quote 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.

  5. #85
    Join Date
    Sep 2014
    Location
    Central New York
    Posts
    59

    Default 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

  6. #86
    Join Date
    Sep 2008
    Location
    Eden Prairie, Minnesota
    Posts
    4,170

    Default 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 at 12:42 PM.

  7. #87
    Join Date
    Sep 2016
    Posts
    6

    Default Re: Dog gears for modular attachments

    Quote 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.

  8. #88
    Join Date
    Sep 2008
    Location
    Eden Prairie, Minnesota
    Posts
    4,170

    Default 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 at 06:58 PM.

  9. #89
    Join Date
    Sep 2016
    Posts
    6

    Default 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)

  10. #90
    Join Date
    Sep 2008
    Location
    Eden Prairie, Minnesota
    Posts
    4,170

    Default Re: Dog gears for modular attachments

    Quote 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 at 02:11 PM.

Page 9 of 9 FirstFirst ... 56789

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Modular Attachment Building - Resources?
    By BlueCheesyFlamingos in forum Robot Game Strategy
    Replies: 13
    Last Post: 08-28-2013, 01:40 PM
  2. Robot and Attachments can't fit in base
    By Einstein in forum Robot Game Strategy
    Replies: 5
    Last Post: 11-04-2011, 01:23 AM
  3. gears
    By will in forum Forum Help / Suggestions / Comments
    Replies: 0
    Last Post: 10-24-2006, 07:56 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •