Articles by tag: tips

Articles by tag: tips

    Sumobot Tips and Tricks

    Sumobot Tips and Tricks By Tycho

    Let's assume you are building a LEGO Mindstorms or Vex IQ based Sumobot, but you want to skip some of the basic mistakes beginners will make. Here are some tips and tricks.

    • Know the rules. It's silly to get disqualified because you didn't pay attention to the rules. Know the size and weight limits. Know the allowed construction materials and techniques. Know the startup behaviors. For example, your robot must not move for 5 seconds after you activate it. This simple rule has tripped up many competitors. And make sure you get to the competition on time to register and get your robot inspected for weight, size and any other requirements.
    • Stay on the field. For this you will almost certainly need at least one light sensor to detect the ring's white edge. We highly recommend two such light sensors placed at the front corners of your robot. This will increase your chances of detecting the edge when coming at it from an angle. You can also adjust your retreat behavior so the robot will be less likely to exit the ring. A retreat behavior usually consists of backing up and turning back toward the center of the ring or scanning for your opponent. You can back up curving away from the sensor that detected the edge first. A third edge detector could be placed at the back of your robot - but this is almost never needed. It would be only useful if you have a behavior that could trigger backing up when the rear of your robot is close to the edge. Theoretically you could detect the edge when being pushed backward by your opponent and try to twist out of the way, but we've never witnessed anyone pulling off this advanced behavior.
    • Build to the maximum weight for the competition. If your bot is heavier than your competitor's, you will have an advantage in traction and with inertia. You will be harder to push around and can more likely push them around. We've seen teams use extra unpowered motors to help maximize weight. Use a scale to be sure you don't exceed the allowed weight.
    • Build compact. Your robot should be as small and dense as possible. Air gaps within your robot and on the exterior should be kept to a minimum. The larger your robot is, the more likely that your opponent will contact a part of your robot far from its center of mass. When it pushes against this part, it will very easily turn your robot in a different direction. Most likely this will be to your disadvantage. You will also be very unlikely to push your opponent in the correct direction when in this condition. Also, the rules say that the first robot to have any part touch the surface that the ring is sitting on is out. If you have a large robot, it is much more likely that part of it will touch-out.
    • Build Low. The lower your center of gravity, the less likely your opponent will be able to topple you or force your wheels to lose traction.
    • Build a Skirt or Shield. A Sumo Shield is a smooth ramp that decends from the front of your robot down to the surface of the ring. The purpose is to create a wedge that will go under your opponent when you come into contact. The wedge will lift your opponent, transferring their weight to your robot. As a result your wheels can increase traction while theirs will decrease. A skirt is a shield that surrounds your entire robot, making it look like a cone or pyramid, so it works wherever the contact point is. But a skirt can be much harder to engineer. They have to be very sturdy, not impede your own movement, and not get in the way of any sensors you might use. Skirts and Shields also increase the size of your robot, so you have more risk of touching-out. Particularly if you have a hinged shield. Hinged shields are great for staying as low as possible to get under your opponent, but they need to be prevented from dropping down when over the edge of the ring. A floating skirt is a wall built around your robot that is only loosely connected or not connected at all to your robot. Instead your robot pushes the skirt around the ring and the skirt's weight keeps it flat against the floor. This makes it unlikely that your robot's motions will create a gap that your opponent can get under. And if your opponent does get under the skirt, they haven't necessarily started lifting your robot to steal traction. You could also have a sensor that detects if your skirt is lifting and back away when that happens.

    We've seen well-engineered robots with only edge sensors win big competitions. A solid, heavy and low robot with a great skirt will conquer when none of its opponents has the same features. Once you are in this category you can consider advanced tips.

    • Locate your prey. Actively seeking your opponent creates an advantage. It's also fun. Usually a forward-facing ultrasonic sensor is a good choice. You can scan for your opponent by making your robot turn in place while checking the sensor to see if it detects something close. Calculate the maximum distance your opponent can be from your ultrasonic sensor. Simply place your robot backed up to the edge of the ring and measure the distance from the front of your ultrasonic sensor to the opposite edge of the ring. Subtract the minimum size of an opposing robot. For LEGO sumos that would be about 6 in. or 15 cm. If you see anything closer than this you can assume that you've detected your opponent. (Or you've detected humans if you've failed to keep everyone at a proper clearing distance from the ring, including the operators) Continue your turn for a fraction of a second and turn on your charging behavior. Make sure you are aware of the minimum distance your sensor can deal with. You will probably want to recess your sensor from the front of your robot so that it will continue to register your opponent even when you are right up against each other.
    • Organize your software. Beginners will often design software that will do one thing at a time and be unable to react until those things are complete. For example, on detecting an opponent, charge for X rotations of the wheel. While the robot is trying to complete those rotations it's not looking at sensors, so it doesn't detect the ring and drives off if it was too close to the edge. We will post a complete lesson on designing software that always lets the highest priority behaviors (back-away-from-the-edge) interrupt the lower priority behaviors (scan-for-prey).

    Adding Blog Features

    Adding Blog Features By Ethan

    Task: Add Cool and New Blog Features

    I remember, vaguely, that someone on our team wanted to add a post counter for all the posts people appear in. And, today, I did it out of sheer boredom. And, here it is.

    {% assign eh = 1 %}
    {% assign dc = 1 %}
    {% assign ed = 1 %}
    {% assign or = 1 %}
    {% assign js = 1 %}
    {% assign cr = 1 %}
    {% assign dp = 1 %}
    {% assign mv = 1 %}
    {% assign tv = 1 %}
    {% assign jc = 1 %}
    {% assign inc = 1 %}
    {% for post in site.posts %}
      {% for name in post.rollcall %}
        {% if name == "Ethan" %}
          {% assign eh = eh | plus: 1 %}
        {% endif %}
        {% if name == "Dylan" %}
          {% assign dc = dc | plus: 1 %}
        {% endif %}
        {% if name == "Evan" %}
          {% assign ed = ed | plus: 1 %}
        {% endif %}
        {% if name == "Omar" %}
          {% assign or = or | plus: 1 %}
        {% endif %}
        {% if name == "Jayesh" %}
          {% assign js = js | plus: 1 %}
        {% endif %}
        {% if name == "Caitlin" %}
          {% assign cr = cr | plus: 1 %}     {% endif %}
        {% if name == "Darshan" %}
          {% assign dp = dp | plus: 1 %}
        {% endif %}
        {% if name == "Max" %}
          {% assign mv = mv | plus: 1 %}
        {% endif %}
        {% if name == "Tycho" %}
          {% assign tv = tv | plus: 1 %}
        {% endif %}
        {% if name == "Janavi" %}
          {% assign jc = jc | plus: 1 %}
        {% endif %}
      {% endfor %}
      {% assign inc = inc | plus: 1 %}
    {% endfor %}
    <ul>
      <li> Dylan Chorley - in {{dc}} posts</li>
      <li> Evan Daane - in {{ed}} posts</li>
      <li> Ethan Helfman - in {{eh}} posts</li>
      <li> Omar Ramirez - in {{or}} posts</li>
      <li> Caitlin Rogers - in {{cr}} posts</li>
      <li> Jayesh Sharma - in {{js}} posts</li>
      <li> Darshan Patel - in {{dp}} posts</li>
      <li> Maximillian Virani - in {{mv}} posts</li>
      <li> Tycho Virani - in {{tv}} posts</li>
      <li> Janavi Chadha - in {{jc}} posts</li>
    </ul>

    Now, this is not obviously the best code, there's probably a more efficient way than creating one variable per person. But, it works.
    We've been making improvements on the site since the season began - changing the theme, Caitlin's commits that updated the blog for the new season, and purging old member bios from the team, just like how Stalin purged political dissidents from pictures and sent them to gulags.

    Edit: We now have a Iron Reign stats page! We have spent a solid two hours debugging this so please appreciate it. We addded Austin, and cumulative personhours for team members and Iron Reign as a whole.

    Reflections

    We still need to work on the blog. At least for my computer, it takes a long time to load the actual site as it loads every single post made, so I'd like to add pagination. As well, I'd personally want to add a second theme for very easy readability, something like this.

    Programming our New Robot

    Programming our New Robot By Tycho, Caitlin, Ethan, and Jayesh

    Task: Program our new mecanum wheel driving platform

    Now that our new robot has been built with a mecanum wheel platform, we can start write our drive code and figure out how to make our robot preform three basic motions: forwards and backwards, side-to-side and to rotate. We decided that, in order to get the best understanding of our robot, how it moves and our code, that we would try to write our drive code through trial and error. However, we did reference some guides written by other various FTC and FRC teams if we got stuck on something and needed to figure out where to start in solving the problem.

    Reflections

    In order to drive our mecanum wheels properly, we need to first discuss how each wheel is placed on the robot, and also how each wheel needs to move in respect to the others in order move in a certain direction. Each wheel has small rollers that point 45 degrees off of the larger wheel itself. In order to properly set up mecanum wheels, the rollers on each wheel have to point towards the center of the robot.

    This is important, because if these wheels are not pointing in the proper direction, then the rollers will begin to fight against each other, causing strange driving patterns that aren't very useful. We learned this the hard way, because when reconstructing the wheel mounts, the positions of two wheels on robot were flipped, causing the robot to drive in circles when we tried to drive sideways.

    The main reason we decided to go with mecanum wheels is because they open so many different ways to navigate the field. Robots that properly use mecanum wheels can not only go forwards, backwards and turn, but they can also make a robot move side to side. These three types of movement can be mixed with each other to do even cooler things like move in diagonals or even strafe, which is when a robot moves in an arc while moving sideways. Of course, we cannot use mecanum wheels to their full potential if we do not first understand the first three basic types of movement. Driving forwards and backwards is pretty simple, and it's the same as any other robot; all of the wheels have to move in the same direction. Turning also remains unchanged from other platforms; the left side of the robot has to move one way, and the right side of the robot has to move the other.

    However, moving side to side is not really intuitive compared to the others. In order to move side to side, the wheels on either side have to move opposite of each other. For example, if I wanted to, from a top-down perspective, drive to the right, the wheels on the left side of the robot would have to drive away from each other, while the wheels on the right side of the robot would have to drive towards each other. The rollers start spinning away from the center and to the right on the left side of the robot, or towards the center and to the right for the right side of the robot. The forwards and backwards components of the wheels and the rollers cancel each other out, and the robot moves to the right.

    Fixing Faulty Encoder

    Fixing Faulty Encoder By Tycho and Jayesh

    Task: Fix a faulty encoder on our robot

    This shows a test of our encoder issues. It might have been a month ago that we noticed a strange behavior in our autonomous code when the robot was moving forward at low speed. It would curve to the right when we were telling it to go straight. We probably would have noticed the problem earlier if we had any kind of subtlety in our driving. But we didn't, partly because the problem goes away when driving at full speed. We did suspect that the problem was in the encoder feedback of the front left drive wheel. In this video you can see how it ramps up to full speed much faster than the other motors. Here we are driving the robot with encoder PID active. But when driving backward, the motor/wheel behaves properly. This indicated to us that one channel of the encoder was working normally while the other was skipping ticks. But the problem could be in the encoder, the encoder cable or the motor controller. Since our motors take some time to change out and we were heading off to the Arkansas State Championship, we decided to simply turn off PID control. The problem goes away when we are simply driving the motors with open loop power levels - proving that the encoder is the culprit and that motor imbalance was not an issue. The problem with just turning of PID control is that we were still getting bad odometry since our method of calculating distance traveled is based on averaging the encoders across the four motors. So we had to adjust our target distances in autonomous based on trial and error instead of proper calculations.

    Here we are trying to identify the source of our encoder issues. We swapped the encoder cable and and ports on the motor controller, but the problem stayed with the front left motor. That told us that it was the motor's encoder that was the issue. We confirmed through telemetry that the encoder was giving no ticks when driving forward, but worked fine in the reverse. So we replaced the whole motor and this time it sped up faster than the other motors in both directions. That really mystified us for a bit. Turns out the substitute motor had an encoder that was dead on both channels. What were the odds of that? We'd simply pulled a motor from our inventory and assumed it would be OK. But it must have been one we hadn't needed to be encoder controlled. We finally found a third motor, this time tested its encoder before throwing on the robot, and all is well now. We can now drive the robot under PID control and it drives as expected at various power levels. We need to re-calibrate our blended travel distances with the working encoder, but feel much better about our performance. We can even reliably use run to position commands if we want, though our navigation code doesn't require that.

    This just shows the proper behavior of the robot after our encoder troubles were resolved:

    Motor Controller Mounts

    Motor Controller Mounts By Ethan, Darshan, Max, and Tycho

    Task: Prevent static shocks to our robot

    Throughout the year, we've dealt with static issues with our robot, as shown here and here. And, now that we've pretty much gotten autonomous and the lift out of the way, the static was our only remaining issue.

    To prevent the static shocks, we needed to isolate the motor controllers and other parts from the metal section of the frame. This was achieved by adding a polycarbonate shield on each side, and mounting the corresponding motor controllers. However, we had to partially remove the swinging arms that we created in the last post in order to mount the siding. We plan to add LEDs on each side of the robot to give the robot some "bling".

    Reflections

    The polycarbonate siding in conjunction with staticide should give us a huge advantage in the robot game for the Jan. 14 tournament. As well, it may net us some design points, as it is a solution to a problem that many FTC teams suffer from.