Announcement

Collapse
No announcement yet.

SoCal Regionals

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

  • SoCal Regionals

    My kids went to the SoCal regionals at Legoland this past Sunday and won "1st Place Strategy & Innovation" for robot design so I thought I'd share some information about our bot. First, here's a video of The Aquabot doing its thing in practice: https://youtu.be/zG_cZ0PktEU

    This was the team's second year together and my fourth year as a coach so their robot and software are pretty refined at this point. We don't prepare any kind of formal presentation about our robot design. The kids just talk off the cuff. I don't know if that helps us or hurts us. The judges seem to expect some kind of presentation, but the kids have no problem winging it. To prepare, I simply ask them to complete this sentence: "a good robot is..." then add an adjective. We've come up with plenty. A good robot is fast, compact, reliable, sturdy, balanced, versatile, neat, strong, etc. Then I ask them to point out a couple ways the robot fits each adjective. For example, a good robot is fast so we used large wheels. If they ever are stuck for something to say, they know to start with, a good robot is...

    For our software, I don't practice, "a good program is..." but perhaps I should. Nonetheless, we made extensive use of My Blocks and comments to make it easier to read. We used 2 light sensors, a gyro, and ultrasonic sensor. The most common construct is: turn motors on, wait for the sensor to detect something, turn motors off. I hammered these three steps until the kids started thinking in this pattern. To spin 90 degrees: start spinning, wait for the gyro to change 90 degrees, stop. To find a line: start driving, wait for the light sensor to see white, stop. To open the claw: turn on the accessory motor, wait for it to stall, stop. We didn't use line following this year (we did last year) but we did use the ultrasonic sensor to follow the wall. For that, we implemented a simple, proportional controller. That was the most complicated thing in our program. However, it also follows a pattern: read the sensor, calculate the error, adjust the steering, move, repeat. Following a line or following a wall is basically the same pattern.

    Last year the navigation was very linear: drive in a line, spin, drive, spin, etc. This year, we created an "arc" My Block and used it extensively. Using different steer angles, the robot will drive in circles of different radiuses. Combine that with the gyro and you get an arc. We were always looking for ways to use arcs to get around obstacles rather than drive, spin, drive. Arcs are faster but require more experimentation to get the right path.

    Our attachments are self-working as much as possible. We like to passively push things and use rubber bands to perform actions. For example, to accomplish M05 Extraction, our attachment uses a rubber band to create a one-way-door that slides over the core samples and then pulls them off. To accomplish M11 Escape Velocity, we use rubber bands to shoot a tire down at the paddle. The bot just pushes the contraption into place and then triggers the rubber band.

    We had two, powered attachments this year and we used a dog gear on the accessory motor to quickly switch between them. Our favorite was the worm gear powered claw that pulls the cone from the docking station. The other was a simple ramp used to roll some tires over M04 Crater Crossing.

    This year we added shock absorbers to the caster ball. This reduced some of the vibrations in bot. We also had better cable management. Some cables were wrapped with different color rubber bands for easy identification, some were looped over hooks, some were locked into guides. The bot is even more compact than last year, and I wouldn't have even thought that was possible, especially considering the new suspension, but there's nary a wasted stud or vacant gap.

    This bot is capable of scoring 176 but even that wouldn't have put us in the top 5 at regionals. There were several teams in the 200's but nobody above 300. I was kind of surprised by that. As I said earlier, I've been to 4 tournaments before this. It's not surprising that competition never goes as smoothly as practice but I anticipate that and plan for it. Every year our bots are reliable enough that my teams have always managed at least one, nearly perfect run at each tournament. This lulled me into a false confidence going into regionals. These tables proved to be MUCH more challenging than I expected. I suspect it might have been the lighting. The theater was fairly dark and there was a giant screen where they projected a, mostly white logo, that brightly lit the tables. That was the lighting when the kids calibrated the sensors. THEN, when the clock started, the screen switched to GoPros mounted over the tables and the light level in the room dropped significantly. Unfortunately, if the light sensors aren't working then none of our programs are working. The kids were crushed as their best run only managed about 95 points. The bot did better than that at qualifiers!

    We weren't alone on that front. There were many, many frustrated teams. In many instances, the bots never even got out of base. It also didn't help that the schedule was packed so tight, there was no opportunity to make any tweaks between runs. They couldn't fix anything. They just had to make three attempts using the exact same program each time. I severely underestimated the variability between tables and environments. Like I said, based on my experience at qualifiers, I thought we had it covered. Nope. Not good enough.

    Attached are some pictures of the team and the bot.

  • #2
    The theater was fairly dark and there was a giant screen where they projected a, mostly white logo, that brightly lit the tables. That was the lighting when the kids calibrated the sensors. THEN, when the clock started, the screen switched to GoPros mounted over the tables and the light level in the room dropped significantly.
    That's a big challenge, I suspect most teams to not expect the lighting to be one of the things that cause variation between setup and Go!.
    FIRST LEGO League Mentor and Referee/Head Referee since 2011.

    Comment


    • #3
      Congrats on the Strategy and Innovation award!

      I'm an old timer, so the teams I coached used the light sensors with the NXT. We never really "calibrated" the light sensors. Instead, we shielded the light sensors so they were always sensing an area of the board that was in the shadows. That seemed to produce generally consistent readings, independent of ambient light levels. The only exception we found was trying to run the robot in broad daylight outside.

      Comment


      • #4
        Originally posted by timdavid View Post
        Congrats on the Strategy and Innovation award!

        I'm an old timer, so the teams I coached used the light sensors with the NXT. We never really "calibrated" the light sensors. Instead, we shielded the light sensors so they were always sensing an area of the board that was in the shadows. That seemed to produce generally consistent readings, independent of ambient light levels. The only exception we found was trying to run the robot in broad daylight outside.
        I saw a robot last weekend with the classic "Harry Potter cape" shielding method. They said it was proof against every light source they could throw at it.
        FIRST LEGO League Mentor and Referee/Head Referee since 2011.

        Comment


        • #5
          Yup, I plan to toss some lego capes into the mix and ask the kids to make light shields. I always thought light shields were for the paranoid. Across 4 qualifiers, they didn't seem necessary. Now I know different.

          I think I'd make the whole calibration thing a little more automated. I'm thinking that the robot should drive itself a couple inches across a line and calibrate itself rather than ask the kids to "place on white" then "place on black". I think they messed that up on the final run. Overall, I'd like a more comprehensive sensor check and calibration procedure at the start of each match.

          Comment


          • #6
            You can turn using arcs without using the gyro. No matter what you use for a steer ratio the value (right motor - left motor) is the same for a given heading change. I performed several experiments comparing turns made using wheel math against those made using the gyro. As long as the robot was free to turn (no obstacles or excessive wheel slip) the wheel math was just as good as the gyro. I don't like using the gyro for anything that last longer than a second. I've talked to a lot of teams this year who are not happy about the mysterious gyro behavior. It appears the favorite use for the gyro is driving in a straight line, and rookie teams (and even not so rookie teams) are stumped when their robot drives in nice consistent curves.

            The radius of arc for a given steer ratio can be computed. You don't have to experiment to get the right value. Back in Smart Move my girls use arcs for almost every move and it can really cut down on the number of moves and sped up the missions. They used a big dividers/compass to plot the arcs (like those used to draw arcs on the chalk board in 1960's geometry classes). That gave them the radius to enter in the move block. Alternatively you could make a big template with arcs for common radii.

            I would be surprised if a small change in illumination would have much effect on the reflected light intensity. Light from a projector bouncing off a screen onto the table is not very intense. It appears intense to our eyes, but our eyes are extremely sensitive. Even if they turned the projector off I would expect the sensor value to barely change when reading AMBIENT light. In reflected light I wouldn't expect to see any change at all, especially if you are using EV3 color sensors. NXT light sensors are more sensitive to changes in ambient light (they have no built in compensation), but you need a pretty bright IR source (not much IR from a projector) to have much affect.

            When I got home I ran a little experiment using my LCD projector. I set the robot on a white sheet of paper and recorded the intensity readings from the two NXT light sensors on the robot and an EV3 sensor I attached for this test. I took readings with the overhead light on and off, and with a 100 watt bulb about 3 feet away. Then I powered up my LCD projector and shone it directly one the robot from about 1 foot away. This is what the sensors reported:

            NXT sensor 1, Dark = 47, Overhead On = 47, Lamp On = 53, Projector only = 50
            NXT sensor 2 = 52, 52, 56, 51
            EV3 sensor = 29, 29, 29, 29

            My robot places all the sensors about 16 mm above the mat with shielding on only one side (facing the robot). Your sensors appear to be better positioned and shielded.

            I have no doubt there was something at the tournament that was different than what you saw before, but I don't think it was the lights.
            Last edited by Dean Hystad; 12-13-2018, 12:45 AM.

            Comment


            • #7
              Originally posted by Dean Hystad View Post
              No matter what you use for a steer ratio the value (right motor - left motor) is the same for a given heading change.
              Sorry, I don't follow this. For example, to drive a quarter circle, I drive until I see the gyro change 90 degrees regardless of the steer ratio. That's just three blocks of code. Turn motors on, wait 90 degrees, stop. Actually, the stop is even optional if the next block is just another motor command.

              Without using the gyro, how do you recommend driving in a quarter circle given a random steer ratio?

              All our arcs and spins were brief, so the gyro worked fairly well. It also compensated for other variables such as the bot accidentally bumping a mission model. We don't use the gyro to drive straight. My other team experimented with that 3 years ago and I learned it wasn't worth it.

              During practice, we did draw circles at various steer ratios with a marker attached to the robot on large paper. This allowed us to see the rough relationship between steer and turn radius. I actually ran the regression myself and figured out the equation for our bot (diameter = (392/steer) - 9) but I thought the math would be too much for the kids. I assume the 9 is because our tires are 4.5 inches apart. I assume the 392 is some function of our tire size. That's where I stopped.

              I do like the idea of a giant compass to measure radiuses on the field. We didn't have anything like that. We just used a tape measure and eyeballed it.

              I don't have a better explanation for the poor performance during competition other than the sudden change in lighting. I could tell by the way the bot was moving that the light sensors weren't acting right. It seems far-fetched to me as well, but it's my best guess. Maybe the kids just always messed up the calibration. The bot seemed to do much better on the practice tables (located outside in sunlight). I dunno. Maybe we're just grasping at straws.

              Comment


              • #8
                I wanted to test the accuracy of the gyro sensor against the accuracy of using rotation sensors. For my test to be fair I needed to perform turns in the same way; start the motors, wait for something to happen, stop the motors. This meant I needed to write an equation that would compute robot heading change based on rotation sensor feedback. When I wrote the equation I was surprised to see that the turning radius cancels out. It doesn't matter if I do a spin turn or a turn with a 10 mile radius; (motor A - motor B) will be the same for the same heading change.

                Lets say the turning radius is the distance from the center of the turn to the inner wheel (or it can be to the outer or the middle). If the robot drives in a complete circle the distance the inner wheel will travel = 2 * PI * Radius, and the distance the outer wheel travels = 2 * PI * (Radius + Track) When you subtract Outer - Inner you are left with (Outer - Inner) = 2 * PI * Track.. Converting this from inches to rotations you get (Outer - Inner) = (2 * PI * Track) / (2 * PI * Wheel Radius) = Track / Wheel Radius.

                If the difference for a 360 degree turn is Track / Wheel Radius, the difference for any turn = (Heading Change in Degrees * Track) / (360 * Wheel Radius).

                Comment


                • #9
                  Here is a great thread on calibrating the EV3 light sensor. Your team might find something useful there that could help prevent the problem you saw, but that's just a guess on my part based on what you said above.
                  https://forums.usfirst.org/forum/gen...tion#post12687

                  Comment


                  • #10
                    Originally posted by Dean Hystad View Post
                    I wanted to test the accuracy of the gyro sensor against the accuracy of using rotation sensors. For my test to be fair I needed to perform turns in the same way; start the motors, wait for something to happen, stop the motors. This meant I needed to write an equation that would compute robot heading change based on rotation sensor feedback. When I wrote the equation I was surprised to see that the turning radius cancels out. It doesn't matter if I do a spin turn or a turn with a 10 mile radius; (motor A - motor B) will be the same for the same heading change.

                    Lets say the turning radius is the distance from the center of the turn to the inner wheel (or it can be to the outer or the middle). If the robot drives in a complete circle the distance the inner wheel will travel = 2 * PI * Radius, and the distance the outer wheel travels = 2 * PI * (Radius + Track) When you subtract Outer - Inner you are left with (Outer - Inner) = 2 * PI * Track.. Converting this from inches to rotations you get (Outer - Inner) = (2 * PI * Track) / (2 * PI * Wheel Radius) = Track / Wheel Radius.

                    If the difference for a 360 degree turn is Track / Wheel Radius, the difference for any turn = (Heading Change in Degrees * Track) / (360 * Wheel Radius).
                    With my team of 9 and 10 year olds, I had to teach them about negative numbers and what happens when you add/subtract/multiply with negative numbers because this is beyond what they have learned in school. We worked for a while testing the idea of using a gyro sensor to help them steer their robot. Compare the math you just described to Turn + Wait for gyro and it is obvious why my kids are using the gyro for turns. Each turn takes 2 blocks, but it is simple enough for them to understand. Put those 2 blocks in a myblock with parameters for power, turning radius, and desired final heading, and it becomes even simpler.

                    They also used the gyro to help make sure the robot was driving the direction they wanted. Of all of the things that went wrong at our first event, gyro failure was not one of them. Their myblock for the gyro is a fairly simple proportional program. They view the board from the viewpoint that the robot starts out at heading 0. If they want to drive to the right, they put in a value of 90 in their myblock. If they want to drive left, they put a value of -90. This allows their turns to be less than perfectly accurate with the robot going the right way afterwards; and it helps if the robot bumps over something or even if a tire is slightly off the wheel.

                    Dean, you're always talking about robust programs that allow the robot to overcome the inevitable problems. This is actually a simple solution to a lot of issues. gyro.PNG

                    Comment


                    • #11
                      Originally posted by Tim Carey View Post

                      With my team of 9 and 10 year olds, I had to teach them about negative numbers and what happens when you add/subtract/multiply with negative numbers because this is beyond what they have learned in school. We worked for a while testing the idea of using a gyro sensor to help them steer their robot. Compare the math you just described to Turn + Wait for gyro and it is obvious why my kids are using the gyro for turns. Each turn takes 2 blocks, but it is simple enough for them to understand. Put those 2 blocks in a myblock with parameters for power, turning radius, and desired final heading, and it becomes even simpler.

                      They also used the gyro to help make sure the robot was driving the direction they wanted. Of all of the things that went wrong at our first event, gyro failure was not one of them. Their myblock for the gyro is a fairly simple proportional program. They view the board from the viewpoint that the robot starts out at heading 0. If they want to drive to the right, they put in a value of 90 in their myblock. If they want to drive left, they put a value of -90. This allows their turns to be less than perfectly accurate with the robot going the right way afterwards; and it helps if the robot bumps over something or even if a tire is slightly off the wheel.

                      Dean, you're always talking about robust programs that allow the robot to overcome the inevitable problems. This is actually a simple solution to a lot of issues. gyro.PNG
                      From what I've seen drive straight using gyro causes more problems than it fixes. I've judged 15 teams this year that use the gyro to drive straight and 6 of them wondered why the robot wasn't driving straight until I showed them the gyro sensor was drifting. This isn't a problem for turning, but the longer you move using the gyro the more the move is affected by drift. I understand why you like it since it hasn't bitten you, but it does bite and it happens a lot. Keep your after turn corrections short and you shouldn't have to worry much. I don't hate the gyro, but I have a strong dislike that is getting stronger. Too much copying badly written "go straight" my blocks. Too little understanding of how the sensor works. Too much confusion and despair when the robot that did go straight (and would probably go straight without the gyro) starts driving crooked. Too much early success that leads to really weak solutions. There is very little to like about the gyro.

                      As for the math, almost all kids in FLL know how to compute the circumference of a circle. I was surprised when I was talking to a bunch of fifth graders who knew nothing about absolute value, but they all knew circumference = 2 * PI * Radius. I judge a lot of teams that program all their move blocks duration in degrees or rotations. Some guess and adjust. Some have a marker on the wheel, count rotations while pushing the robot and adjust. Some push the robot and use sensor view and adjust. A few even make a tape measure that uses their wheel's circumference. Quite a few know they can convert distances to rotations by dividing by the circumference, but do the conversion by hand and type in the value. I sometimes show these teams how to make a my block that converts inches or centimeters to motor rotations and moves the robot (It chews up 4 minutes of program judging where I don't have to ask "What does this move block do?"). I think I may have done this 12 times this year and it is always really young teams and they always know the equations for a circle.

                      If you know how to write a my block that drives the robot some number of inches and you know how to calculate the circumference of a circle you know all the math to do any kind of turn. Young kids may not know how to do symbolic math, but they can solve for a known radius. If you solve for many different sized circles and the answer is always the same there must be something interesting going on. I used a similar process when working with a group of first graders who discovered PI. When we measured how far a robot moves for each rotation of the motors and divided that number by the measurement printed on the side of the tire we kept coming up with the same number. How can that be?
                      Last edited by Dean Hystad; 12-13-2018, 12:56 AM.

                      Comment


                      • #12
                        Originally posted by Dean Hystad View Post
                        The radius of arc for a given steer ratio is can be computed. You don't have to experiment to get the right value. Back in Smart Move my girls use arcs for almost every move and it can really cut down on the number of moves and speed up the missions. They used big dividers/compass to plot the arcs (like those used to draw arcs on the chalk board in 1960's geometry classes). That gave them the radius to enter in the move block. Alternatively you could make a big template with arcs for common radii.
                        Last year, we were using curves quite a bit. But we were going low-tech by simply putting it in port view, manually moving the robot in the arc we wanted, and recording how far the left wheel moved and how far the right wheel moved. The ratio between the distance traveled by the wheels is the same as the ratio of the power provided by the motors. For example, if the left wheel goes 8" and the right wheel goes 10", the ratio is 8/10 = 0.8. Then we'd create a move tank block and enter 80 for the left power, 100 for the right power (or 40-50 or 20-25 or whatever, as long as the ratio was still 0.8), and 10" as the distance (the equivalent of 10" in degrees of motor rotation of course). That was enough to get us in the ballpark of the path we wanted to travel, then we'd tweak from there.

                        Comment


                        • #13
                          Power/Speed for the steer block for positive steer and power is:
                          Left Motor = Power
                          Right Motor = Power * (1 - steer * 0.02)

                          For negative steer the right motor runs at the commanded power.

                          The speed ratio, and thus the distance ratio is:

                          Power / (Power * (1 - steer * 0.02)) = 1 / (1 - steer * 0.02)

                          The speed ratio is equal to the ratio of the circumference and is also equal to the ratio of the radii. If the robot is driving inside an arc of radius R (distance from center of turn to outer wheel) we have:

                          R / (R - Track) = 1 / (1 - steer * 0.02)
                          or
                          R - R * steer * 0.02 = R - Track
                          or
                          R * steer = Track / 0.02
                          or
                          R = 50 * Track / steer

                          For your robot (4.5" track) this works out to be:

                          R = 225 / steer

                          Test for Steer = 50, R = 225 / 50 = 4.5, Correct. Pivots about one wheel, Radius = Track
                          Test for Steer = 100, R = 225 / 100 = 2.25, Correct. Pivots about point between wheels, Radius = Track / 2

                          If you want to drive along a 25 inch radius arc:
                          Steer = 225 / Radius = 225 / 25 = 9

                          Or a 9 inch radius arc:
                          Steer = 229 / 9 = 25

                          If you want to measure turn radius at the inner wheel the equation changes to:
                          R = 225 / steer - 4.5

                          I've found this equation to be fairly accurate. I attribute the small amount of error to not providing an accurate track measurement and wheel scrub.
                          Last edited by Dean Hystad; 12-12-2018, 11:19 PM.

                          Comment


                          • #14
                            Originally posted by Dean Hystad View Post

                            From what I've seen drive straight using gyro causes more problems than it fixes.
                            My sample size is smaller than 15, but of the two teams I'm working with, one is using a gyro sensor and the other isn't. Both teams have really good robots, but if my life depended on a lego robot getting to a certain spot on the table, I'd go with the robot using the gyro every single time. ;->

                            Comment


                            • #15
                              Originally posted by brian@kidbrothers.net View Post

                              Last year, we were using curves quite a bit. But we were going low-tech by simply putting it in port view, manually moving the robot in the arc we wanted, and recording how far the left wheel moved and how far the right wheel moved. The ratio between the distance traveled by the wheels is the same as the ratio of the power provided by the motors. For example, if the left wheel goes 8" and the right wheel goes 10", the ratio is 8/10 = 0.8. Then we'd create a move tank block and enter 80 for the left power, 100 for the right power (or 40-50 or 20-25 or whatever, as long as the ratio was still 0.8), and 10" as the distance (the equivalent of 10" in degrees of motor rotation of course). That was enough to get us in the ballpark of the path we wanted to travel, then we'd tweak from there.
                              I tried this and it is difficult. I even wrote a program that calculated the ratio and displayed it on the screen while I pushed the robot and I still found it really hard to follow a fair arc. I think it is similar to drawing a circle. Some people can draw a pretty good circle freehand and I am not one of them.

                              There is no difference between the Move Tank and Move Steer block other than how the ratio is computed. I'm sure you are aware of this, but many of the teams I judge are not. I see a lot of teams that use Move Tank for going straight and Move Steer for turns or vice versa and think the way they are using the blocks is the only way you can control the robot. I have hardened my heart against the disappointment I see when I inform them that these closely held beliefs are completely wrong. Were I to use raw move blocks I would pick Move Steer just because it allows changing power without having to type in two numbers. When you bury the move block inside a my block the choice doesn't matter at all. There really is no good reason for picking one block over the other.

                              Using the Move Tank block the equation is:

                              Ratio = (Radius - Track) / Radius
                              or
                              Radius =Track / (1 - Ratio)

                              If we use your ratio of 0.8 and WiliamFrantz's 4.5" wide robot the radius of the outside wheel = 4.5/(0.2) = 22.5

                              Just in case you were wondering a 0.8 ratio is equivalent to steer = 10. (Ratio = 1 - Steer * 0.02)
                              Last edited by Dean Hystad; 12-13-2018, 12:51 AM.

                              Comment

                              Working...
                              X