Announcement

Collapse
No announcement yet.

Help going straight using gyro

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

  • #16
    Originally posted by peter schuyler View Post
    A backward straight gyro program has a different algorithm (b-a)*c, so essentially you would have to double the number of myblocks so you could go either forward or backward.
    Or you could include a switch block that runs a different algorithm for positive and negative power. This code should handle both. During the holidays, I was also toying with the idea of a gyro turn block that could handle forward or backward turns to right or left. It first checks if it is steering right or left, then checks whether it has positive or negative power. I haven't tested this, since I don't have a robot at home, but in theory, something like this should work, right? (I'll find out once I have a chance to test it.) Including some logic in the block will also help limit the number of myblocks you are working with.

    Sorry for the pictures as PDFs... I couldn't get them to load so they were readable.
    Attached Files
    Last edited by Tim Carey; 01-06-2019, 09:47 PM.

    Comment


    • #17
      Originally posted by Dean Hystad View Post
      Last year I judged a team that used "follow gyro" blocks for all moves. Their programs contained no obvious turns or straight moves because every command could be a turn and a straight move. To change the robot heading (turn) all they did was specify a heading that was different than the current heading.
      This is what my team did during our qualifier event. They made almost no "turns" and just used the gyro follower to make the robot go where they needed it. I am encouraging them to make some turns where they need a tighter turn, but otherwise, it works really well. We never reset the gyro sensor during a match because we found that the inevitable errors will compound and make the missions fail.

      Comment


      • #18
        Originally posted by Tim Carey View Post

        Or you could include a switch block that runs a different algorithm for positive and negative power. This code should handle both. During the holidays, I was also toying with the idea of a gyro turn block that could handle forward or backward turns to right or left. It first checks if it is steering right or left, then checks whether it has positive or negative power. I haven't tested this, since I don't have a robot at home, but in theory, something like this should work, right? (I'll find out once I have a chance to test it.) Including some logic in the block will also help limit the number of myblocks you are working with.

        Sorry for the pictures as PDFs... I couldn't get them to load so they were readable.
        No need for switch blocks. The difference between tracking backward and forward is the sign of the gain. You can do that by changing the equation, but that muddies the waters in my opinion.

        If the forward equation is : Turn = (Command - Feedback) * Gain
        You could write the backward equation as: Turn = (Feedback - Command) * Gain
        Or you could write it as: Turn = (Command - Feedback) * (-Gain)

        To have a different gain for forward and backward you could process the gain input based on the sign of the power input:

        Gain = Input Gain * Power / | Power |

        Switch blocks should be used when different condition demand different actions. Things like changing the sign of a number can be done using a math block

        BTW, I don't see an pictures or PDF. Am I missing something?
        Last edited by Dean Hystad; 01-06-2019, 11:19 PM.

        Comment


        • #19
          Originally posted by Tim Carey View Post
          I was also toying with the idea of a gyro turn block that could handle forward or backward turns to right or left. It first checks if it is steering right or left, then checks whether it has positive or negative power. I haven't tested this, since I don't have a robot at home, but in theory, something like this should work, right?.
          Wait for gyro change covers forward, backward, CW and CCW turns. Everything gets easier when you forget about sign and work in local coordinates. When you find yourself using a bunch of switch boxes to handle different cases that often indicates your logic could be optimized.

          I was playing with an equation to compensate the gyro reading for lag so I could do fast turns with little error. At first I had cases for FW CW, FW CCW, REV CW and REV CCW turns. After playing with the math a bit I realized that all cases were the same and the equation that worked for every case was shorter than the equations I had written for special cases. I had to write a comment to document the derivation because it still looks wrong each time I see it.

          I bet your gyro turn block idea will be much the same. Sure you can have special cases for CCW and REV, but I bet there is an equation that works for every case and you'll end up not needing any switch blocks at all.
          Last edited by Dean Hystad; 01-08-2019, 07:29 PM.

          Comment


          • #20
            I'm a third grade teacher doing FLL after school, not an engineer, so would you mind sharing how you did it? I saw that the exit condition is the same for FW CW and REV CCW because they end pointing the same direction, and same for FW CCW and REV CW. I considered using the change rather than measure, but I think I got stuck somewhere doing that (can't remember clearly). Anyway, here are the pictures (if they process correctly) of what I was trying.
            Capture.PNG
            gyro.PNG

            Comment


            • #21
              I will use a simple gyro turn block as an example. No proportional speed control or other lag compensation techniques, though those too have genrric solutions. My robot has the following behavior when turning:

              Code:
              Steer  Power  Gyro
                +      +     +
                +      -     -
                -      +     -
                -      -     +
              Looking at this I see 4 different combinations of power and steer so I think I need four different cases for my turn block. Using input Power, Steering and Duration these four cases are expressed as:

              Code:
              If Steer > 0 AND Power > 0
                 stop = gyro feedback + Duration
                 moveSteerOn(steer, power)
                 wait until gyro feedback >= stop
              else if Steer > 0 AND Power < 0 THEN
                 stop = gyro feeedback - Duration
                 moveSteerOn(steer, power)
                 wait until gyro feedback<= stop
              else if Steer< 0 AND Power > 0 THEN
                 stop = gyro feeedback - Duration
                 moveSteerOn(steer, power)
                 wait until gyro feedback<= stop
              else
                 stop = gyro feedback + Duration
                 moveSteerOn(steer, power)
                 wait until gyro feedback >= stop
              moveSteerOff
              Each case looks strikingly similar:

              Code:
              Compute final gyro angle
              moveSteerOn(steer, power)
              Wait until gyro feedback reaches final gyro angle
              Notice there are four cases, but only two different courses of action. I do one thing if power and steer have the same sign and something else if the signs differ. A simple test for same sign is the product of two numbers having the same sign is not negative. Using my same sign test I can condensed the code:

              Code:
              If (steer * power) >= 0
                 stop = gyro feedback + Duration
                 moveSteerOn(steer, power)
                 wait until gyro feedback >= stop
              else
                 stop = gyro feeedback - Duration
                 moveSteerOn(steer, power)
                 wait until gyro feedback<= stop
              moveSteerOff
              As mentioned before the cases are very similar. Reviewing the math I see that I can simplify the code more if I stop worrying about which direction the gyro moves and only look at how much the signal changes. In other words I might be able to forget about the sign and only look at the magnitude. I will assume the robot turns in the correct direction. Using absolute value I can get rid of the separate cases:

              Code:
              start = gyro feedback
              moveSteerOn(Steer, Power)
              loop until (abs(gyro feedback - start) >= duration)
              moveSteerOff
              You don't have to be an engineer, just familiar with basic math and good at spotting patterns. Spotting patterns led to condensing the logic from four cases to two. Basic math helped me see I really don't care where the gyro angle starts or ends, all I care about is how much the signal changes. An additional benefit is this code works for "backward" mounted motors and upside down mounted gyros. It doesn't care.

              Using the EV3 Wait Change block the code is even simpler.

              Code:
              moveSteerOn(Steer, Power)
              wait until gyro change(Duration, either direction)
              moveSteerOff
              If you have trouble with Wait Change it is usually because the wait change is used right after a reset. You should never reset a sensor just before using the sensor in a Wait Change block.
              Last edited by Dean Hystad; 01-10-2019, 08:00 AM.

              Comment


              • #22
                If you use the flat view for the switch block you can wire between blocks inside and outside the switch. This would remove the need for using variables as a way to pass parameters into the switch block. I see a lot of teams that use variables instead of wires and it is a bad idea. Not only does it make your programs longer and harder to read, but variables are a global resource and it is really easy to reuse a variable where it is not meant, or safe, to be used. Imagine the confusion if you had a variable named "Intensity" that was used inside your "MoveGyro2Line" block that you decided to reuse in a mission to hold the intensity value for white. Go searching for a black line and your saved white intensity value mysteriously changes to black.

                When attaching images to a post I use the Large view for a few blocks and Thumbnail for images with many blocks. Directly pasting a large image in a post usually results in something that is shrunk too small to see important details. For really large pieces of code it is best to attach the EV3 file.

                Here's my interpretation of your forward/backward move gyro block. The MoveStart block hides the fact that my robot drives backward with a positive power command, and the Distance my block measures how far a point midway between the wheels has moved and has a convenient comparison that I use to know when the robot has driven some distance.

                GyroStraight.JPG

                Here's a program that uses the my block to drive a square path. No turns required. Kind of a fun way to command the robot but it complicates path planning. The turns are kind of odd, starting with a spin for the first 40 degrees (due to gain = 2) then straightening out over the last 50 degrees. You end up pointing in the desired direction, but the point where you started is not on the line you end up driving, there is a little sideways motion due to simultaneously driving and turning.

                Square.JPG
                Last edited by Dean Hystad; 01-11-2019, 05:02 PM.

                Comment


                • #23
                  I had to look the code over a few times before I totally got how it works (making sure that I understood the myblocks you described), but I think I get it. I only used the variables so I could show everything at once. I usually do use the flat view and wire in. If I remove those, the code is considerably shorter and simpler. I approach coding with the idea of how I can guide my 4th and 5th graders to it. We did use the turn/wait for change in gyro 2-block method most of the time (and that is probably good enough, really). It is probably all you need, now that I'm thinking about it, especially for FLL with 9 and 10 year olds... As far as the gyro follower goes, the "gain" value is a good way to eliminate the need for a switch. The math is a little much for a 9 or 10 year old, but it's not out of their reach with a little math session. Thanks for explaining.

                  Comment


                  • #24
                    Originally posted by Tim Carey View Post
                    I had to look the code over a few times before I totally got how it works (making sure that I understood the myblocks you described), but I think I get it. I only used the variables so I could show everything at once. I usually do use the flat view and wire in. If I remove those, the code is considerably shorter and simpler. I approach coding with the idea of how I can guide my 4th and 5th graders to it. We did use the turn/wait for change in gyro 2-block method most of the time (and that is probably good enough, really). It is probably all you need, now that I'm thinking about it, especially for FLL with 9 and 10 year olds... As far as the gyro follower goes, the "gain" value is a good way to eliminate the need for a switch. The math is a little much for a 9 or 10 year old, but it's not out of their reach with a little math session. Thanks for explaining.
                    You could use a switch to get the gain. It may turn out that your robot needs different gain values (not just sign) for tracking forward and backward.

                    Comment


                    • #25
                      The other point in the switch is the greater than/less than on the exit command. I suppose you could use absolute value to make it irrelevant, but it is one more math block versus a switch.

                      Comment


                      • #26
                        Tim,

                        I judged yesterday and interviewed a team that used the gyro sensor for combined turn/straight moves. First time I've seen that done by a team on purpose. I asked if the offset introduced during the combined turn/drive segment at the start of the move made it harder to plan their paths an they swore the robot turned first and then went straight (Partly true but the shift was visible when running the robot). They did something interesting with distance. Their block zeroed distance until the tracking error was less than 5. This subtracts most of the turn distance so the robot drives the requested distance.
                        Last edited by Dean Hystad; 01-13-2019, 12:20 PM.

                        Comment


                        • #27
                          My kids mostly just guess and check when they are doing their turns this way. They would use port view and roll the robot to where they wanted it to end up. Then they input the new direction and what they saw in port view as the distance, then make adjustments as needed. I have not worked with them to measure the distances on the board in inches or cm because it was always just easier to measure the distance needed in degrees with the robot in port view. It is just another unit of measurement, in my opinion, in which they have a great measurement tool (rolling the robot forward).

                          Comment

                          Working...
                          X