Announcement

Collapse
No announcement yet.

Help going straight using gyro

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

  • #31
    Originally posted by Tim Carey View Post
    Peter, would you mind sharing how you use the variables to change course/heading? Post an image or a copy of your ev3 file?
    Capture.PNG
    Here are our two myblocks. One for straight, one for turning:
    straight.jpg

    left.jpg

    Comment


    • #32
      Why do you have loops in your turn block? They don't do anything other than mess up the move block's synchronization and power regulation.

      I see this pattern used a lot when I am judging, and it doesn't make much sense. What I think is the natural progression on using sensors does not lead to a move block inside a loop unless you are changing the power or steering. Here it is used in place of a wait. And it is almost always the gyro sensor that is used this way. When teams drive until they see a black line they use Move On, Wait for RLI < 10, Move Off. When I see the same team wait for the gyro angle to change they do this loop thing. The only reason I can think of is the team started using the gyro by copying a gyro drive straight block.
      Last edited by Dean Hystad; 01-31-2019, 04:51 PM.

      Comment


      • #33
        Originally posted by Dean Hystad View Post
        Why do you have loops in your turn block? They don't do anything other than mess up the move block's synchronization and power regulation.

        I see this pattern used a lot when I am judging, and it doesn't make much sense. What I think is the natural progression on using sensors does not lead to a move block inside a loop unless you are changing the power or steering. Here it is used in place of a wait. And it is almost always the gyro sensor that is used this way. When teams drive until they see a black line they use Move On, Wait for RLI < 10, Move Off. When I see the same team wait for the gyro angle to change they do this loop thing. The only reason I can think of is the team started using the gyro by copying a gyro drive straight block.
        I'd hafta ask the 10 year old who programmed it, but I imagine you're right -- he had programmed a straight gyro drive and then adapted it to make a turn. As long as it works the way they've programmed it, I don't know why I'd correct the kids.

        Comment


        • #34
          Originally posted by Dean Hystad View Post
          .. I think is the natural progression on using sensors does not lead to a move block inside a loop unless you are changing the power or steering. Here it is used in place of a wait. And it is almost always the gyro sensor that is used this way. When teams drive until they see a black line they use Move On, Wait for RLI < 10, Move Off. When I see the same team wait for the gyro angle to change they do this loop thing. The only reason I can think of is the team started using the gyro by copying a gyro drive straight block.
          Yes, I see this technique (loop instead of a wait) quite frequently when judging programming also. I've seen it used with a color/light sensor also. I can only speculate that for some kids, having the robot loop until the condition is satisfied makes a little more sense than turning on the motors and waiting. I know when first programming the NXT move blocks, some kids were skeptical of the "Unlimited" setting on the duration. They didn't believe the robot would keep moving forever with one move block. And of course, if they put that one move block in a program alone without another block following it, the program ended quickly, which seemingly justified their suspicions.

          I also wonder if some kids think the loops look more impressive in the program code. I know our Minnesota judging rubrics specifically call for the proper and effective use of loops. I think some teams believe using a loop counts for more in judging than using a wait block.

          Comment


          • #35
            I judged programming at the Minnesota state tournament Saturday. I think there were a few teams there that read this forum. Multiple times I heard teams use the term "heading" to describe their gyro following.

            At the tournament we divide teams into 6 judging groups. Each group has their own set of judges who interview 10-11 teams in the morning. In the afternoon we have callbacks where a panel of judges interviews the highest ranked team from each judging group. I got to judge in the morning and in the afternoon, so I saw a lot of really impressive robots and programs. There are a lot of teams doing some really good work and it made my job quite difficult and quite a lot of fun.

            Far and away the most commonly used sensor at the tournament was the gyro. Most of the teams using the gyro use it to control turns, and a fair number of teams use the gyro to follow a heading. One team used the gyro to follow a heading but use rotation sensors to control turns because they claimed it worked better (Note to FLL teams, if you make a claim like this your design judge will ask how you came to such a conclusion. If you performed experiments and made your decision based on the results this is a great way to differentiate yourselves from the 30 other teams that have a PID line follower or a mission sequencer). There were also high scoring teams that used every sensor except the gyro. The highest scoring and most consistent team of the day didn't use the gyro sensor at all. I think I interviewed 6 teams that used sensors but eschewed the gyro because it was "undependable" and "didn't provide much benefit" (more unsupported claims or opportunities for discovery depending upon your point of view). These teams had great solutions that were really reliable and were well represented at the top of the scoreboard. The teams relying on the gyro sensor didn't do as well. Nearly all of those teams had to re-run some of their missions during the interview and their table scores were not near their theoretical maximum scores. Go figure.

            At best this is anecdotal evidence from a biased source, but It is what I observed and something to think about. Unless the gyro has a problem I think that driving is more repeatable using the gyro than not, but does more reliable driving produce a more reliable solution? Is the gyro helping you design a good solution, or does it make a crummy solution work "good enough" that you are passing on developing better and more robust solutions? From what I saw Saturday, "good enough" is not good enough to win because other teams are making robots that are smarter and using solutions that are more creative and clever.
            Last edited by Dean Hystad; 02-26-2019, 06:23 PM.

            Comment

            Working...
            X