Page 3 of 3 FirstFirst 123
Results 21 to 30 of 30

Thread: Getting the kids to work together

  1. #21
    Join Date
    Apr 2014
    Posts
    170

    Default Re: Getting the kids to work together

    This is kind of hi-jacking this thread title, but I have to ask if you can share a bit about "the ability to do arcs without the errors of Move Steering block".
    What kind of errors do you mean? It's no problem to drive in nice arcs with move steering or move tank. I don't think there are any more errors than driving straight.

    Thanks!

  2. #22
    Join Date
    Sep 2008
    Location
    Eden Prairie, Minnesota
    Posts
    4,170

    Default Re: Getting the kids to work together

    I am merciless with teams that use motor degrees or rotations. It is the worst possible way to do robotics and it teaches the worst possible lessons. Teams run from the room in tears, stung by the lashing of my tongue.

    Ok, so that doesn't happen, but I still think commanding robot motion using motor rotations is a bad thing for a team. The mighty power of programming is abstraction. We couldn't write the simplest program without it. The Move block already provides a tremendous amount of abstraction. Dropping one block on the program sequence is enough to make the robot move. We don't have to worry about how that program is translated into a file that is loaded onto the EV3. We don't have to worry about how files are downloaded. We don't have to worry about how bluetooth works or how to write a driver for our bluetooth radio. On the EV3 side we don't have to know anything about how the interpreter runs the file. We don't have to know how the controller communicates with the motors. We don't have to worry about how the OS selects and runs files or what services are required. Without all this abstraction I couldn't write a simple "Hello World" program. Abstraction is amazing stuff.

    So what does this have to do with using port view and programming motion in motor degrees or rotation? Well, this abstraction is such a powerful tool that I think its the first thing a team should learn. I don't want my team to be satisfied with what "comes in the box". When I hear someone say "I wish there was a block that" the opportunity is seized and learning ensues. In the past I started programming with a Move Inches bloc. This his year I started out with iteration and sensor following. Either way the desire is to get the team thinking less about what the robot does and more about making it do what we want it to do. It is easy to program a move in rotations, but that really isn't what we want to do, that is what is provided by LEGO. We can use the power of abstraction to bend the software to how we want to work. When you think about it, programming robot motion using motor rotations is stupid. How far does a move of 72 degrees move the robot? Do you want the odometer in your car reporting travel distance in wheel rotations? How many rotations to Zumbrota (Home to Minnesota's only functioning covered bridge). Should speed limits be in RPM?

    I don't think for a minute that stupid is that stupid does (Sorry Forrest), but if you do stupid things those things should be evalulated. It takes about one minute to convince a new team that commanding moves using motor rotations is not a good solution. One minute to start them down a path to not only writing better programs faster, but also to learning how to program better and become a maker of tools instead of a user. If we don't use motor rotations or degrees to control motion what choices are available? My car's odometer measures distance in miles, and that works really well for driving around town or to other cities. An FLL table is only 0.0015 miles long, so miles probably isn't a good choice for FLL. Yards or feet are a better match for the size of the table, but it is awkward converting base 3 or base 12 measurements into decimal numbers. Inches are a really good fit for the distances an FLL robot travels. Most US kids have a good handle on inches, but we still have the problem that most rulers divide inches into sixteenths. As long as you stay with 1/4 inch increments (0.25 inches) this isn't much of a problem. I like mm because it is the natural unit for LEGO and I never have to worry about decimal places. Centimeters is another good choice. Which one you choose doesn't matter much as long as the unit is about the right magnitude so you aren't typing in tiny little numbers or really big numbers. Now we've had a nice conversation about units and the importance of picking appropriate units. Did you know that engineering wasn't possible until people agreed on a standard set of units? Without units the numbers we use are meaningless, and if our units don't agree it is like using different words to name the same thing. If I call the building I live in a "house" and you call it a "fuloolie" we are going to have a hard time running a construction business. Hey, we just had a conversion about standards and how they are important for communication. What a bunch of neat learning opportunities and we have yet to write a single line of code.

    So how do we convert our linear measure to motor degrees? There is no block that lets us put in inches (hey, we just searched through all the action blocks!). Does anyone have any ideas? Maybe we should try an experiment. Lets command the robot to drive 10 rotations and use a ruler to measure how far the robot moves. What did we get? Is it always the same? You never want to run a test or experiment just once and accept the results (more learning). So 10 rotations moved the robot 70 inches. How far will the robot move if we command the motors to turn 1 rotation? How far should I command the motors to move if I want the robot to move 3.5 inches. Hey, there appears to be a causal relationship between the amount of motor rotation and the distance the robot travels. Because it is a causal relationship we can use it to make predictions. This is perhaps the cornerstone of the scientific method. Why is there this relationship between the motor rotation and the robot travel distance? Oh, you think it has something to do with the distance around the tire? Let's measure. Hey, our tires are 7" in circumference, and that is the same distance the robot travels for one rotation. Not only do we have a causal relationship, but we now have a explanation. We should try a different wheel and see if the relationship between wheel circumference and travel distance holds? Did we just discover a law? Wow, this is heady stuff.

    Now that we know the relationship between motor rotations and robot travel distance how can we use that to make a program that converts from inches to motor degrees? We'll probably have to use math. Computers are really good at math, so we should always try to have the computer do our math. Look, here's a block for doing math. We can even type in an equation with up to four variables. A variable is a place holder for a number. It lets us write an equation symbolically. A symbolic equation can be used over and over with different values for the variables. Hey, I think we are doing algebra! To get the information from the math block to the move block we have to use data wires. Did you know a lot of teams never use data wires? Yeah, I think that's sad too. Programs without data wires is like us working on something and not talking to each other. Each block just does their "thing" and they don't work together. With wires we can make this math block and this motor block do something completely new. Working together makes it work better (a little core values lesson). Wow, with the computer doing the math it is really easy to write a program that makes the robot drive 1 inch or 1 foot or 27.5 inches. It would be nice if we didn't always have to use two blocks each time we want to make the robot move. It is so easy to make a mistake, and entering that circumference each time is a pain. I wish there was a way to combine the blocks into one and a way to make the computer remember the circumference. What are these My Blocks? Hey, this is really cool. What parameters do we want to adjust in our Move my block? Inches of course. How about power and steering? Yeah, I think those are good. What about wheel circumference? I don't know about that one. If I have a wheel circumference input and I change my wheel size I'll have to change the circumference number fore every move. If I hide the number inside the block I only have to change one number and that number is changed for every move. I like that information hiding, that is something we'll probably use again.

    There is so much you can learn doing something as simple as writing a MoveInches my block. Mathematical modeling, scientific method, data analysis, software design, programming and testing, software design concepts, engineering concepts, history, even teamwork and communication. Why anyone would want to pass up a chance like this is beyond me.

    As for being quirky, all teams are quirky. I just don't let that interfere with learning. Doing things the same way year after year is stagnation. The only things that should remain constant are curiosity and a desire to improve. When I work with the same team for multiple seasons we not only build a brand new robot and write brand new software, but we try to solve the problems in a different way. Yes, what we learned should be built upon, but we have to be careful that it doesn't hold us back.
    Last edited by Dean Hystad; 01-07-2017 at 01:10 PM.

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

    Default Re: Getting the kids to work together

    Quote Originally Posted by Rbbbbb View Post
    But Dean, dnb, timdavid, stop and consider this for a moment. Boot the robot, put it in base with the back against the West wall, perhaps with the right side of the robot on the edge of the red LEGO rectangle in base. You're going to plot a path to the gorilla. Go into Port View. Roll the robot forward, keeping the robot pointed due East, the two numbers in Port View about even. Stop when it's about even with the refrigerator. Read the travel distance, in degrees, from Port View. Imagine putting that into a Move Steering Degrees, straight arrow. Exit port view, re-enter Port View. Put your finger on the left wheel to hold it steady, roll the right wheel around until you're pointing at the gorilla. Read the number from Port View, and imagine putting that into a Move Large Motor. Exit Port View, re-enter Port View, roll straight forward to the gorilla, read your number and you're there.

    That was pretty easy and very fast, wasn't it?
    Driving to the gorilla is two straight moves and a turn. This is described in 18 steps above and that is supposed to be "easy" and "fast". It is easier and faster than writing a move block and a turn block and using them to write a program to drive to the gorilla, but by the time you start working on your third mission the more efficient move blocks have overcome those initial time savings.

    If you write a Move block and a Turn block the sequence is:

    1. Place robot stand-in next to gorilla, positioned to deliver food.
    2. Measure distance from back bumper to wall. Put that distance in a move block. This is your last move.
    3. Move robot standing straight south until it is up against the wall. This is where we will square up after the turn.
    4. Add a square up to wall block to the front of your program.
    5. Using your preferred turning method, turn the robot stand-in so the back is facing the base.
    6. Add a 90 degree CCW or left turn to the front of your program
    7. Measure the distance from the back bumper to the east wall. This is how far the robot drives before making the turn. Put this distance in a move block. This is your first move.

    This is another benefit of abstraction. Abstraction lets you use external tools instead of port view. This changes how you view navigation. Using port view you focus on moving the robot. Not using port view lets you focus on where you want the robot to be.
    Last edited by Dean Hystad; 01-07-2017 at 10:40 AM.

  4. #24
    Join Date
    Sep 2009
    Location
    Minnesota
    Posts
    1,607

    Default Re: Getting the kids to work together

    Quote Originally Posted by Rbbbbb View Post
    ... But also coach the two kids beside him to look back and forth from the judges to the speaking child, and then nod in agreement at the end. Is this a gimmick, a fake? Maybe, but these are young kids and after a while it catches on and becomes very real.
    That would definitely be an improvement over a couple teams I judged this season. For those teams, almost every time a child answered a question about the robot, another child spoke up and disagreed with them.

    Child one: "For this mission, the robot uses the color and gyro sensors."
    Child two: "No it doesn't."
    Child one: "Yes it does."

    It was somewhat amusing to watch as a judge, but definitely not the best way for a team to present itself. It was sometimes hard to find the truth until we look at their programs.

    Oh well. I still see lots of wonderful teams with interesting bots and attachments, and many articulate and enthusiastic kids. Many teams have practiced how they want to present the information on their bot in robot design judging, and that's fine. It doesn't have to be scripted, but teams should know which team members will run the robot, which team members may give a running commentary about the bot as it does missions, which kids will answer programming questions if there is a separate judge for that area (as in Minnesota).

    And the team members should definitely know which sensors are used for which missions.

  5. #25
    Join Date
    May 2012
    Location
    Greenville, SC
    Posts
    178

    Default Re: Getting the kids to work together

    Quote Originally Posted by tjhawkey View Post
    This is kind of hi-jacking this thread title, but I have to ask if you can share a bit about "the ability to do arcs without the errors of Move Steering block".
    What kind of errors do you mean? It's no problem to drive in nice arcs with move steering or move tank. I don't think there are any more errors than driving straight.

    Thanks!
    You didn't hi-jack this thread. I did it first, and I put up a huge lightning rod! Try the following code, and see the problem, but then please read the caveats at the end too.

    Try the following code that uses a move steering:

    MoveSteeringProblem.JPG

    Then run it a bunch of times. Then keep running it over the course of a practice, as the batteries drain down. It has been our experience that we see the longer-moving-motor go 100 degrees, usually exactly, but occasionally off by 1 degree. The shorter-moving-motor varies by several degrees, and usually tends to lag more as the battery power goes down.

    But:
    A) Don't take my word for it, try it yourselves, we may well have oversize robots and beat up equipment. (We do.)
    B) The problem is only a few degrees, and code that depends on a degree or two of accuracy is not repeatable on Lego League tables.
    C) The problem was much worse back in NXT, and you might well decide that the behavior is okay in EV3.
    D) It is very affected by the size of the wheels, and somewhat affected by the robot loading. (rotor-to-load inertia, if you're an engineer.)

    I'm about to rebut at length the other posters here, but I'll say this: Kids that do their own work, with their own beliefs and methods, and argue for it well, I don't care if they chose square wheels, they're doing it right. My kids believe that Move Steering is best avoided, they find it clunky and hard to get the arc right.

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

    Default Re: Getting the kids to work together

    The built in arcs for EV3 are MUCH MUCH MUCH better than NXT, but you are correct that it has the same deficiency, the move ends when the motor driving the longer distance reaches its destination. The reason EV3 is MUCH MUCH MUCH better is because the EV3 has MUCH MUCH MUCH better servo control than NXT.

    Since the EV3 has MUCH MUCH MUCH better servo control than the NXT you might get better arcs by computing inner and outer motor powers and performing the move using two motor blocks. You will not see any improvement computing inner and outer motor power and plugging the number into the Move Tank block. The Move Tank block works EXACTLY the same as the Move Steer block, the only difference is the interface for entering the steer.

    The advantage of using two motor blocks instead of a move block is motor blocks are guaranteed to reach their destination. They may not reach their destination at the same time, which will affect the "shape" of the turn, but they will always turn the correct amount, which affects the change in heading. When turning you are usually most concerned with the change to the heading.

    Teams I worked with since EV3 came out have had very good luck using arcs with the gyro. This gives a best of both worlds solution. The move block does is synchronize thing, trying to get the shape right, and the gyro sensor takes care of getting the correct heading. Changes in battery power will change how well the motors synchronize, so there will be some following error variation. Since the heading is managed by the gyro sensor this variation manifests as changes in arc length. If the slower motor is trailing, the resulting arc is a little shorter, and the robot doesn't always stop in the same place. With our mantra of "A sloppy robot is a happy robot" fresh in mind we don't care much about these small displacement errors which are quickly fixed by some other means.
    Last edited by Dean Hystad; 01-09-2017 at 04:34 PM.

  7. #27
    Join Date
    Sep 2008
    Location
    Eden Prairie, Minnesota
    Posts
    4,170

    Default Re: Getting the kids to work together

    Quote Originally Posted by Rbbbbb View Post
    I'm about to rebut at length the other posters here, but I'll say this: Kids that do their own work, with their own beliefs and methods, and argue for it well, I don't care if they chose square wheels, they're doing it right. My kids believe that Move Steering is best avoided, they find it clunky and hard to get the arc right.
    As a judge, I care most about the kids doing the work and how they came to their solution. I would discuss the pros and cons of using motor degrees or rotations to control robot motion, and I would win that argument (it only takes a minute, maybe 90 seconds for a deeply entrenched team), but the affect of using degrees to control your robot will have almost no effect on the evaluation. Nor does using a my block to command the robot to drive in inches. I will give that team props for making a my block and using data wires and the math block, but I would give the same bump for a my block that does something with a sensor. I care very little how a team commands the robot around the mat, as long as it doesn't involve much odometry, but that doesn't stop me from thinking you are absolutely crazy for passing on an obvious home run pitch. MoveInches is too easy and teaches sooo many valuable lessons.
    Last edited by Dean Hystad; 01-09-2017 at 11:38 AM.

  8. #28
    Join Date
    May 2012
    Location
    Greenville, SC
    Posts
    178

    Default Re: Getting the kids to work together

    Quote Originally Posted by Dean Hystad View Post
    As a judge, I care most about the kids doing the work and how they came to their solution.
    Having read that, I will drop my tedious arguments. I completely acknowledge that a MoveCm MyBlock is an optimum way to coach a team and for a team to run motors. In another thread some day in the Programming section, I'll rehash my arguments that degrees (not rotations!) are the "natural unit," and are also a good way to program, but that is not appropriate here.

    People in this thread are worried about HOW to coach teams to work together. When one of the most prolific and accomplished posters and one of the most prolific and contrarian posters square off about a technical point, it's a lot of fun for those two posters but the final lesson is that both of us want very much to be good judges and respectful of the kids work.

    I listed some of my "tricks and gimmicks" that have seemed to encourage team work. My former team members may well roll their eyes and say "no, Coach, we learned how despite your overly obvious and un-subtle tricks."

    I'd love to hear other simple implementable tricks that coaches have to encourage team work or GP. I need them too.

  9. #29
    Join Date
    Sep 2008
    Location
    Eden Prairie, Minnesota
    Posts
    4,170

    Default Re: Getting the kids to work together

    Quote Originally Posted by Rbbbbb View Post
    Having read that, I will drop my tedious arguments. I completely acknowledge that a MoveCm MyBlock is an optimum way to coach a team and for a team to run motors. In another thread some day in the Programming section, I'll rehash my arguments that degrees (not rotations!) are the "natural unit," and are also a good way to program, but that is not appropriate here.

    People in this thread are worried about HOW to coach teams to work together. When one of the most prolific and accomplished posters and one of the most prolific and contrarian posters square off about a technical point, it's a lot of fun for those two posters but the final lesson is that both of us want very much to be good judges and respectful of the kids work.
    I'm the contarian, right? And rotations are obviously the correct choice for programming the robot IF you want to command motor duration directly. Degrees! Who do you think you're kidding?

    I judged design this weekend. Recently I've been judging programming, so it was a nice change. The programming judge I worked with was a poor match. I need someone like Tim David (conscientious clock watcher and all around dependable person) to keep me on track, but this guy was as gabby and oblivious as me. This resulted in 20 minute conversations with teams and a backlog that I hope didn't cause any problems. Even though this was a second round tournament, most teams ran out of things to talk about after 10 minutes and I got to fill in the gap. It gave me a lot more time to talk about how and why. Some of the teams were a bit shaken, and some of them really shone. Some of the questions I asked:

    Q: The way you use your gyro is giving you very accurate turns. Can you see any problems with having a really accurate robot?

    A: (Stunned silence) I suppose that could make you rely too much on the robot doing everything right, and if there was a problem it couldn't recover.


    Q: You use a lot of sensors and mechanical alignment. That is making your missions really reliable. Can you think of any problems associated with having such good tools to use?

    A: (Shocked looks) I guess having solutions to lots of problems could stop you from looking for other solutions, and that might stop you from finding a better solution.


    Q: So this mission works 10 out of 10 times. Is it good to have missions succeed when you test, or is it better to have them fail?

    A: (Quizzical looks) I guess you don't learn much when the missions always work. If it fails you at least know one thing that can make the mission fail.


    Q: Who's more valuable, a skilled and organized operator or someone who makes a lot of mistakes?

    A: A skilled operator, of course!

    Q: Why did you design your solution so it requires a skilled operator?

    A: We didn't!

    Q: Then why is it important to have a skilled operator?


    Some of the questions wandered into the realm of teamwork and core values.

    Q: Who works on what?

    A: (Canned) We all work on everything.

    Q: That's nice, but if you have a programming problem and you can't figure out the answer, who do you ask for help?

    A: (Pause, look over shoulder at coach, shrug) Josh. Josh is probably our best programmer. Other team member nods, other team member says "Yeah, I learned a lot from Josh."

    All teams will have a Josh who shines a little brighter at a particular skill. Good teams acknowledge this. Really good teams take advantage of it, not only getting the most out of Josh, but using Josh to make everyone better. Don't be afraid to bring this up during your design, project, or teamwork interview. Always remember that honest answers are always the best, no matter the question.

    Each of these questions is like a little core values exercise. It was fun to see how the team worked together to come up with the answer. When your team is busy building and programming you could inject similar questions. I think core values is central to being successful in FLL, but I seldom do "team building" exercises. Things like helium sticks or standing in a small area are good ice breakers, they can point out teamwork problems, and they can be fun, but they do little to improve teamwork and even less to embed core values. Instead my teams work on core values all the time in everything we do. I have a big core values poster I bring to meetings and I occasionally ask team members to explain what one of the core values means, or cite an example of where they used a core value during their school day or with their parents.

    A short story that is only related because it also happened while judging this weekend. One of the teams I interviewed had a complex gear train and they described their preload mechanism. It consisted of two gears on an axle and they twist the axle slightly before engaging the teeth, turning the axle into a spring. I said "I remember that idea", and one of the team members opened up a binder and displayed a very familiar document. I tabbed back to the cover page, pointed at the author's name then at my name tag. "I know that guy". The kid's eyes got as big as saucers. I had to laugh. I don't see "Building LEGO Robots for FIRST LEGO League" much anymore. I wrote it before this kid was born. Made my day, which was already going pretty well.
    Last edited by Dean Hystad; 01-09-2017 at 09:53 PM.

  10. #30
    Join Date
    Oct 2016
    Posts
    1

    Default Re: Getting the kids to work together

    Quote Originally Posted by Dean Hystad View Post
    A short story that is only related because it also happened while judging this weekend. One of the teams I interviewed had a complex gear train and they described their preload mechanism. It consisted of two gears on an axle and they twist the axle slightly before engaging the teeth, turning the axle into a spring. I said "I remember that idea", and one of the team members opened up a binder and displayed a very familiar document. I tabbed back to the cover page, pointed at the author's name then at my name tag. "I know that guy". The kid's eyes got as big as saucers. I had to laugh. I don't see "Building LEGO Robots for FIRST LEGO League" much anymore. I wrote it before this kid was born. Made my day, which was already going pretty well.
    My kids had their second-round tournament this weekend. Design Judging was our first event, which makes them nervous, because "the robot never works at the first event." We walked in the room, and I saw a name tag with "DEAN" hanging around the judge's neck, and I thought "well this is gonna be fun!" You asked about their split gears on the drive train, and I wondered if they'd ever figure out that you wrote the book where they found that...indeed, I wondered if they'd even remember they had a copy of it in the binder!

    We've followed these forums for a couple of years, and eventually, we figured out that the same author's name was appearing in many informative posts, so we Googled you and found the book. They scrolled through most of it, but enjoyed the sections on gears and pulleys, and decided that the split gear would solve a lot of problems. I never did get them to actually test it, compared to a simple gear train...

    Many thanks, Mr. Hystad, for sharing so much of your knowledge and experiences. We've had a lot of fun learning from your work!

Page 3 of 3 FirstFirst 123

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. Kids Do the Work?
    By Dammz in forum Coaching & Team Management
    Replies: 6
    Last Post: 01-06-2015, 01:30 PM
  2. New coach - I've got my ten kids, now what?
    By MrGreg in forum Starting a Team
    Replies: 21
    Last Post: 06-18-2014, 03:33 PM
  3. Quiet kids
    By eljay in forum Miscellaneous
    Replies: 6
    Last Post: 12-02-2012, 12:05 AM

Posting Permissions

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