INTO THE DEEP DeepAutoAscend3

Prerequisites/Assumptions

You can probably follow along even if you’re new to Blocks, however this tutorial doesn’t explain how to program in Blocks.

This is a much more complex program than the first program because it makes use of motor encoders and an IMU and has more steps in it. It is based upon the RobotAutoDriveByGyro sample program. It makes use of the same driveStraight, turnToHeading, and holdHeading functions in that sample program to perform the basic movements of the robot.

• RobotAutoDriveByGyro sample program

Plan

Have the robot drive push three samples into the net zone and then park on tile D3 where it completes a level 1 ascent by touching the lower rung. This is a program can only be used on the Red Alliance and from a starting position near the red net zone. It will score 6 points for the samples and 3 points for the level 1 ascent for a total of 9.

The robot will follow the paths shown by the green line. The robot stays in the front part of the field moving back and forth to push 3 samples into the net zone and then park on tile D3 where the robot raises and arm to touch the lower rung. The robot didn’t have time to push the last sample on the spike mark. Completing a level 1 ascent is worth more than trying to get that last sample into the net zone. That a common theme in more advanced AUTO programs is that there is only so much you can do in the time available.

Competition Manual Section 11.3 Pre-Match rule G303 indicates robots must start touching the Field wall and not be in the net zone or observation zone.

Unlike DeepAuto2, this program will be based on the RobotAutoDriveByGyro sample program. That program has Blocks functions we can use to move and turn. That makes the main part of our program easier to follow.

We’ll start the robot in a fixed starting position with the front and rear wheels of the left side of the robot pressing against the wall and the front of the robot aligned with the edge of tile F2 closest to the red net zone. This fixed starting position means we don’t need to carefully align or point the robot every time we set up.

The steps this program will need are:

1. turn away from the wall and point at the net zone
2. drive forward into the net zone
3. back up leaving the first sample in the net zone
4. turn so the rear of the robot faces the sub
5. back up towards the sub and stop on tile E2
6. turn to face the first sample on the floor
7. drive forward until we touch that sample
8. turn to face the net zone
9. push our second sample into the net zone
10. back up and stop on tile E2
11. turn to face the front of the field
12. drive forward a little bit
13. turn to face the second sample on the field, we should be lined up pointing at the net zone
14. push our third sample into the net zone
15. backup to tile E1
16. turn so the rear of the robot faces the sub
17. backup until we get to tile E3 and stop
18. active the servo (our “arm”) so that it raises and touches the lower run of the sub. That completes a level 1 ascent.

To save time, most of the holdHeading blocks that would normally be used after a turn have been disabled so the AUTO program completes before the end of the AUTO period (30 seconds).

DeepAutoAscend3

The program was created in 3 stages. I started by creating a DeepAutoAscend program that pushed one preloaded sample into the net zone, then doing a level 1 ascent. I copied that to a DeepAutoAscend2 program and changed it to push two samples into the net zone before completing the level 1 ascent. Finally, I copied it to a DeepAutoAscend3 program that scores 3 samples and the level 1 ascent.

Unlike the My First and Second Program tutorials, I’ll just show you the final program and discuss the highlights.

If you want a copy of the .blk file you can find that here. You can download the file to your laptop and then upload it to Blocks. The program assume you have a servo called servo1, in addition to the left_drive and right_drive motors.

You’ll note that the main part of the program mostly consists of function calls like turnToHeading which takes a turn speed and heading as parameters.

• the IMU will report a heading that is positive as the robot turns counter clockwise. To turn away from the red alliance wall when facing the net zone we need a clockwise turn, which is why the heading is set to -25.

To move the robot forward the program uses the driveStraight function, which takes a drive speed, distance and heading as parameters. driveStraight will check the IMU and adjust the driving so that the robot stays on the indicated heading.

• The distance is 24 so the robot moves forward 24 inches. The comment says 18″ which was what I used early on, but I missed updating the comment when I updated the actual distance. The comment should just say what I’m trying to get the robot to do in this step, something like: “Drive forward and push sample into the net zone”.
• Assuming you’ve adjusted the COUNTS_PER_MOTOR_REV and WHEEL_DIAMETER_INCHES to match your motor and wheels than it is really convenient to be able to specify a number of inches you want to move. You can use a tape measure on the field and put together a rough program very quickly. Then adjust the turns and distances as needed to actually accomplish actions on the field.
• Note how the program maintains the heading of the last turn. In the first step we turned clockwise to -25 degrees. We use that same heading in our driving logic. If you don’t, the robot will attempt to turn and drive and the same time. I’ve avoided doing that I think it would lead to more wheel slips/skids which are bad when trying to use the motor encoders.

There is also a holdHeading function. This simply holds the robot in place, but checks the IMU and will rotate the robot to maintain a heading.

• I started this program by always calling holdHeading after a turnToHeading. I have noticed that holdHeading will sometimes adjust the robot slightly. I think there’s probably some variance in using turnToHeading where the robot might come to rest either a little short of the target heading or a little past it. HoldHeading attempts to fine tune the robot heading more accurately.
• However, this AUTO program was taking too long trying to get the third sample and actually ran out of time in the 30 second AUTO period. I tried to keep the turn and driving speeds a low as possible to reduce wheel slip. I ended up disabling most of the holdHeading function calls. Because the driving logic is using the same heading as the last turn, any slight variance in actual heading after the turn should be corrected during the driving.

The main part of this program becomes a series of turns and moves using those three main functions. Have a look at the complete program to check out those functions. There are also many helper functions that those functions use. If you decide to use the high level functions in your programs , you’ll also have to copy the low level functions.

1. moveRobot – this function takes a driveSpeed parameter and a turn parameter and uses those to set the motor power levels. The driveStraight function uses moveRobot and supplies a turn parameter based on the IMU heading that causes the motors to apply slightly more power to one wheel and less to the other which causes the robot to adjust course as it drives.
2. getSteeringCorrection – this function takes a desiredHeading and a proportionalGain parameter. This function is used by driveStraight to get the turn value needed for moveRobot. The current heading from the IMU is compared to the desiredHeading and the difference is multiplied by the proportionalGain parameter (which is a small number) so that we get a small turn value that we can use to adjust course. Using a larger proportionalGain parameter cause quicker adjustments, but too large a value can cause the robot to twitch back and forth.
3. getHeading is a simple function that returns the IMU Yaw value.
4. sendTelemetry is a function that has a parameter called straight which should be a true or false value. Three main functions call this function to display telemetry. The driveStraight function sets the straight parameter to true, while the other main functions set the value to false. If straight=true additional telemetry blocks are called to display the target and current encoder values on the driver station.

Turns are probably where this robot is the weakest, although it lines up on a heading pretty well, due to wheel skips/skids the robot may not always be in the right position. Sometimes the robot would spin in place, other times it would execute more of a turn where one wheel was not providing the same traction as the other wheel.

You might notice that this robot has red gaffer tape (cloth tape) on it’s wheels. That’s because the rubber on these old Tetrix wheels is hard and shinny and the wheels were slipping a lot. The cloth tape provides slightly better traction so the turns and moves worked a little better.

After all the moves and turns the robot should be parked on tile E3 so it’s time to raise the arm and complete the level 1 ascent.

Your robot may vary depending on what motors you are using and the size of the wheels you are using. Adjust the power levels and motor encoder targets appropriately.

If you don’t have a field for testing, you’ll need to have a space that’s about 6 feet wide and 4 feet tall (which is three tiles wide and two tiles tall – see the video for what that should look like).

Here’s the robot running this program.

For all that work, this robot only scores 9 points in the AUTO period. However, 6 of those points will score again at the end of the match.

Next Steps

You should have a look at last year’s tutorial on motor encoders and using the IMU. When you have lots of steps it makes sense to use Functions that you can call to do the work of each step. That helps shorten the main part of the program, make it easier to read, and there are fewer Blocks to copy around.

• RobotAutoDriveByGyro_Blocks – FIRST Robotics BC

This year the RobotAutoDriveByGyro program is available as Blocks sample program and I recommend you create that program learn about working with encoders and the IMU. It’s a good example of a complete Blocks program that makes use of functions.

We’ve reached the limit of what a simple pushbot can do in the AUTO period. A single preloaded specimen on the high chamber is worth 10 points. Also, a pushbot will have almost nothing to do in the TELEOP period since it cannot get samples out of the sub without some sort of collector or arm, nor can it complete a level 2 or 3 ascent. You’ll want to add mechanisms like an arm and gripper/collector so that the robot can pick up samples from the sub and either hang specimens on the chamber or drop samples in a basket.

Check out the official FIRST build guides. There are example “starter bot” robot build guides for the various kit of parts. These are not meant to be highly competitive concepts, but rather designs that are easy to start working with using your starter kits and minimal additional resources. Ideally you enhance, improve and iterate on these designs to make your competition robot awesome.

Getting Help

It is often possible to use Google (or other search engine) to get help or solve problems. There are lots of resources online. If you’re still stuck you can ask for help here.

You can also check out last year’s tutorials on creating autonomous programs for CENTERSTAGE.