Announcement

Collapse
No announcement yet.

Help going straight using gyro

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

  • Help going straight using gyro

    This code works normally but when i added the color sensor part to it it no longer works and just spins to the left (made into a myblock for easy use) need help fast if possible; thanks!

  • #2
    Did your know your gyro straight block runs for time? Using loop counts is an odd choice. As for the color sensor version, look at how you calculate the steer.

    Comment


    • #3
      Originally posted by Canine8_YT View Post
      This code works normally but when i added the color sensor part to it it no longer works and just spins to the left (made into a myblock for easy use) need help fast if possible; thanks!
      You're using addition in the one math block and multiplication in the other. But I'm with Dean -- why use a number of loops? How far does the robot actually move? It just goes for however long the computer takes to run the calculations?

      Comment


      • #4
        Originally posted by Dean Hystad View Post
        Did your know your gyro straight block runs for time? Using loop counts is an odd choice. As for the color sensor version, look at how you calculate the steer.
        Originally posted by brian@kidbrothers.net View Post

        You're using addition in the one math block and multiplication in the other. But I'm with Dean -- why use a number of loops? How far does the robot actually move? It just goes for however long the computer takes to run the calculations?
        thank you! as for why i use loops idk i kinda just forgot to change it to time

        Comment


        • #5
          I had toyed with the idea of creating a myblock with the gyro block, math block, and move steering block (with parameters for power and direction) and putting inside a loop block each time I wanted to use it. Then each loop block could be set to a different sensor. You could use the same myblock to exit after x rotations or on a white line or a touch sensor or a timer... We also do not reset the gyro during a run, only at the start of a run, so we would leave that out.

          Comment


          • #6
            Why include the gyro block? A proportional control block is a valuable thing to have. You can use it to follow a line using the light sensor or a wall using the ultrasonic sensor. And if you are so inclined you can even use it with a gyro sensor though I have no idea why anyone would want to do that.
            Last edited by Dean Hystad; 12-14-2018, 04:50 AM.

            Comment


            • #7
              Originally posted by Dean Hystad View Post
              And if you are so inclined you can even use it with a gyro sensor though I have no idea why anyone would want to do that.
              We are in a thread with the title "Help going straight using gyro"... ;->

              Comment


              • #8
                Originally posted by Dean Hystad View Post
                Why include the gyro block? A proportional control block is a valuable thing to have. You can use it to follow a line using the light sensor or a wall using the ultrasonic sensor. And if you are so inclined you can even use it with a gyro sensor though I have no idea why anyone would want to do that.
                Sometimes the tread come loose from the wheel and the kids don't notice in the heat of competition. Sometimes an attachment designed by 9 year olds after school ends up unbalancing the robot a little. Sometimes the competition mats have wrinkles that affect one wheel more than another. Sometimes the motors are unbalanced with one being a little behind the other. Sometimes the battery is a little low.

                There are probably other things too, but this is a short list of the top of my head. Using proportional gyro control allows the robot to compensate for all of those things. It makes the robot more reliable in the face all the things that can go wrong on competition day. Point the robot and hope it goes the way you want it to go isn't a good plan.

                The one criticism of the gyro sensor that I've ever heard is that sometimes it gives a false sense of drift, but if you know how to fix that, it is a powerful tool. It has helped my team a great deal over the past two years.

                Comment


                • #9
                  Just for fun, I was playing with this idea last year. Use the gyro sensor to control the power of the robot during a turn. Turns start fast and slows down as they get closer to where you want to end up. I didn't show it to the kids because they were doing fine without it, but maybe some time... Seems fitting to share it here. gyro.PNG

                  Comment


                  • #10
                    Tim,

                    This looks great. Our team had developed a gyro turn code for reducing power as the robot got close to it's final gyro target value. It exited on gyro value. It worked great most of the time, but it would sometimes stall when the robot was loaded with attachments. The problem was that the power would get so low that the robot couldn't finish the turn. Your solution looks like it solves the exit on low power issue, but I worry that as the power gets low, the loop might exit before the robot could complete the turn.

                    Then one member of the team found this video by Nate Simpkins. https://www.youtube.com/watch?v=pbSzYKahLjk

                    Nate used a switch to turn at higher speeds early in the turn and then slow down to 4 power for the last bit of the turn. This prevents the stall at low power for the end of the turn. The team incorporated a variation on the switch concept into their existing myBlock and credited Nate during their robot design presentation. The team's new turn myBlock worked great in both practice and at competition.
                    Last edited by jasponti; 12-15-2018, 02:31 PM.

                    Comment


                    • #11
                      My first effort at this had the same issue so I had it exit at a time. I also added a little extra (2-5) into the math block so the power would never hit 0. I tested it on my kitchen floor so I could track its direction in increments of 90 degrees. I ran a couple of squares and then just made it spin in place for fun. So this is gyro turn myblocks and gyro straight myblocks. youtu.be/yX0s2Mv15wE

                      Comment


                      • #12
                        We should really stop referring to this as "going straight". Using a gyro this way does not make your robot drive straight, at best it keeps the robot pointing in the same direction, at worst it makes it drive in circles. If the program makes any steering corrections at all the robot will diverge from a "straight" line to a series of parallel lines. Usually each correction moving the robot further and further from the initial line. Unless your robot has a serious mechanical problem it drives a straighter line without any steer correction than it will using a gyro to maintain heading. However, driving straight is less important than driving in the desired direction, and a gyro can help with that (it can also turn all your "straight" moves into arcs).

                        Using the wrong terms to describe something leads to confusion. When you say the gyro makes the robot go straight there is a whole lot of confusion when the program that used to drive straight starts driving in an arc. How was the gyro making the robot go straight? Why did it stop making the robot go straight? What broke? When you say you steer the robot to make the gyro angle equal some value this behavior causes less confusion. You know the problem is either with how you steer or what angle the gyro reads. If the program worked before or works sometimes and you didn't change how you steer (either algorithm or gain) the problem is probably the gyro. How can I check the gyro? Using the correct terms practically leads to the solution.

                        If you really want to drive in a straight line you need to do something like Itay.Y describes in his videos; adjusting the robot heading to keep it pointing at it's destination. This too should not be referred to as going straight, but it will keep you closer to a straight line than maintaining a heading. It adds the complication of having to continually update a COMPUTED position (Itay refers to this as "tracking", but you cannot track the robot position using a gyro and rotation sensors, you can only compute where the sensors think it is), but at least when you tell the design judges that you use a gyro to drive straight you wouldn't be completely wrong.
                        Last edited by Dean Hystad; 12-26-2018, 06:23 PM.

                        Comment


                        • #13
                          a good straight gyro straight proportional program starts with a gyro reading before the loop. This reading is essentially your course and will go by wire to the A slot in an advanced math block within the loop. Next, start the loop, the first block within the loop is another gyro reading -essentially where you are at that moment - which goes to the B slot in the math block. Now for the math block. the first parameter will be ADV (advanced). next set the top right hand part of the ADV math block to the algorithm (a-b)*c The first gyro block outside the loop goes by wire to slot A in the math block, the second gyro block inside the loop goes to B and C is a multiplier to increase the difference between the A and B reading so that there will be more of an adjusted turn (We usually set C at 5, lowering it to 2 immediately after you have made a turn) and leave D blank. The next block is a move steering block set to 'on'. A wire will go from the '=' sign in the math block to the arrow (direction) parameter in the move steering block. Set the speed. Finally, you determine how you want to end the loop. You can choose any of the parameters, but mostly you will choose either Rotations (after starting before the first 'course' gyro block with a rotation sensor block set to 'reset' with the port set to wheel b in both the motor rotation sensor and the end of loop port); Color sensor -reflected light intensity to look for a black or white line; Time, touch sensor or ultrasonic sensor.

                          The reason you usually don't use this as part of a myblock is simply because there are so many different possibilities to end the loop and the algorithm which cannot be changed by a myblock. 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. Our team calculated that we would need 12 myblocks just to cover all the possibilities for going straight and decided not to clutter up our brick screen with all these possibilities. Also, by writing this loop over and over in their programs they learn it with all its intricacies.

                          Comment


                          • #14
                            I like it when teams separate the looping logic from the control logic. It demonstrates an understanding of abstraction that I is really hard to show using a string of move commands (even fancy my block move commands). There is no reason for teams to have a line follower and a gyro follower and a ultrasonic follower because these are all the same. Sure there is a different sensor, and maybe a different setpoint, and most likely a different gain, but the math is identical and the differences can be all be handled using parameters. Either very few teams see the similarity, or they are unwilling to diverge from each block being a step in a sequence of motions that accomplishes a mission.

                            I understand why teams like to fit everything in one block. It makes for shorter programs. This can lead to several different line followers or several different gyro heading followers, but it doesn't have to be that way. When you really understand how your line follower works and your gyro follower works and your ultrasonic follower works you should see that there are ways to make a follower block that works for all. I am reminded of a team that had a 30 degree turn block, 45 degree turn block and 90 degree turn block (as well as ccw versions of each). They were shocked to see that the duration of the 45 degree turn was 1.5x the duration of the 30 degree turn and half the duration of the 90 degree turn (minus a small adjustment). They never developed an understanding of turning that led to a universal solution.

                            Writing a bunch of blocks that do pretty much the same thing is an indication that you don't really understand what those blocks are doing. Why would you have a gyro follow block that drives some distance and another block that drives until a light sensor sees a line? Those are really similar. If you look at the code you'll see that almost all the blocks are the same. Is there any way to treat "when to stop" in an abstract manner? Why do you have a gyro follow block and a line follow block? Aren't those nearly identical? Is there some way to treat "read sensor" in an abstract manner?

                            There are likely only three ending conditions for any kind of following block. Follow something for an amount of distance, follow something until a light sensor sees dark or light, follow something until a touch sensor is pressed.. This can be generalized into an input for what is the duration type (until distance until line, until touch), and what is the duration target (how far a distance or a light sensor reading). Heck, I guess you could probably write one follower block that handled all cases. Parameters would be:

                            What is the feedback sensor
                            What is the threshold value
                            What is the proportional gain
                            What is the base power
                            What is the duration type
                            What is the duration target

                            I would still rather see an abstraction for following inside a loop (so it could be combined with other behaviors), but a team that encapsulates the abstract idea of following inside a my block would be ok too.
                            Last edited by Dean Hystad; 01-06-2019, 11:37 AM.

                            Comment


                            • #15
                              Originally posted by peter schuyler View Post
                              a good straight gyro straight proportional program starts with a gyro reading before the loop. This reading is essentially your course ...
                              This is how your team writes the block, and it is probably better than resetting gyro angle, however it is not a requirement for being "good". 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. Different teams solve these problems different ways, and I think that is great.

                              You do not specify a "course" when using the gyro, you specify a "heading". A "course" requires adjustment to the "heading" for environmental conditions. When sailing or flying you travel through a moving fluid and the heading must be continually adjusted to stay on "course". Traveling on land also requires "heading" changes to stay on course due to terrain. Only in the flat world of FLL are "course" and "heading" similar enough that a mixed understanding of the two doesn't leave you completely lost.
                              Last edited by Dean Hystad; 01-06-2019, 07:23 PM.

                              Comment

                              Working...
                              X