Auto Programming

[gordonfdsa]

47 Autonomous workflow

Oct 19:

• Updated the code to match with the driving path for the autonomous period of the game from stratgey operations.
• Auto still needs to a bit of testing as some of the methods(functions/code) need to be debugged.
• Likely a logical conditional statement error which causes a loop to run permanently in the autoclass447 file.

[gordonfdsa]

Tele Op: Implemented Tank Drive:

• uses both left and right joysticks of the controller instead of the previous macanum drive. (macanum drive uses the left joystick to move in all 4 directions, and the right joystick to rotate the robot)
• uses the left joystick forward and backwards to control left side of the wheels.
• uses the right joystick forward and backwards to control right side of the wheels.
• may further implement this depending on driver preference

Reconfigured the robot motors, now its working as intended Autonomous movement/vision next

[DreamChaser0719]

Auto:

• Tested motors which did not move, reason unknown
• Modified Auto code to achieve more reasonable movement distances
• Likely the battery ran out, will investigate it next meeting

[gordonfdsa]

May use MeepMeep to implement and test roadrunner auto, which will have more precise movements than the current encoder system.

[gordonfdsa]

.

[gordonfdsa]

Nov 2:

• fixed motor configurations in driver station (a device which runs the control hub(which is something that serves as a connection tool between code and robot hardware).
• robot ports were rewired
• build had robot for majority of the meeting

To do:

• Auto drivetrain(basically the movement part of the robot, so the 4 wheels and the base) still needs to be tested and fixed
• initialize secondary motors and servos(those are the add ons to the 4 wheels and base to make the robot have other functions for the competition in the code)
• work on vision

[gordonfdsa]

Nov 8:

PID controller

• The motor rotates at a non- constant power due to how electricity works.
• As the motor rotates at a non constant power, it causes variations in the speed of the robot.
• Using this PID control loop will make the robot more precise than purely encoders (setting the robot motor at a destination which is a constant, and have the robot motor rotate until it reaches that position e.g. 300 ticks).

Basically, its a calculation which takes in the inputs of:

1. where the encoder position (e.g. 300 ticks) is currently at and
2. where the encoder position is set to be. (e.g. 2000 ticks) In order to calculate the power to set the robot to. the output of this calculation will be the power which the robot should be set to for optimal movement.

The formula is: f(t) = (Kp)P(t) + (Kd)D(t) + (Ki)I(t), where t represents any given time and f(t) determines what power the robot should be set to at that given time.

Kp, Ki, and Kd are constants which will eventually be tuned according to robot.

First term {(Kp)P(t)} is the Proportional term. P(t) is basically [set encoder distance - current encoder distance] at any given time t, meaning how much further the robot have to go until target location.

Second term {(Kd)D(t)} is the Derivative term. D(t) calculates the instantaneous rate of change of how fast the error is changing, and this is used to try to keep the error constant. For instance, taking two points on a graph of a curve, if you connect those two points, you will get a slope using (y2-y1)/(x2-x1). However, imagine the x values of two points moving closer towards each other, then the line which connects those two points will be almost tangent to the curve at that specific x value. This line represents the instantaneous slope at that specific x value. The code basically uses the error of the encoder distances from the last iteration and the current iteration of the loops as the y1 and y2 values, and the time at the last iteration and time at the current iteration as the x1 and x2 values. this is how D(t) is calculated.

• Mainly uses Proportional and Derivative terms to modify the speed of the robot, Integral term is negligible.
• Need to tune the constant Kp and Kd values when robot is available.

Another way to think of this is you want to robot to go fast when its far away from your target location, but as it closes in, you want to gradually decrease power so it doesn't overshoot and comes to a nice stop, we can achieve this by using the Proportion term. As the robot gets closer to the location, the target encoder position - current encoder position will be smaller, thus resulting in a smaller power, recall that f(t) is the power which the robot will be set to at a given time.

However, this will encounter issues as for example, the motor doesn't rotate at constant power, so when you set the power to 0.5, it actually moves at 0.48, which will make the code less accurate, this is what the D(t) attempts to do, such that when you set the power to 0.5, it actually moves at 0.5 speed.

For more details, visit: https://gm0.org/en/latest/docs/software/concepts/control-loops.html

[gordonfdsa]

Nov 23:

Added secondary controls. Motors and Servos are basically the same thing, motors have 360 degree continuous motion and more power, while servos have a limit of usually 270 degrees rotation and less power.

Current motor and servo setup (excluding drivetrain): Motors: DcMotor Intake (Intakes the pixels) --> Done DcMotor Sliders (The linear slider which moves the board up and down, actual motor rotates a string spool which pulls on the sliders) --> Done DcMotor Climbing1 (for the robot to hang during endgame, one on each side of the robot) --> Done DcMotor Climbing2 (for the robot to hang during endgame, one on each side of the robot) --> Done

Servos: Servo DropperTop (The top servo to drop the pixel from the board) --> Done Servo DropperBottom (The bottom servo to drop the pixel from the board) --> Done Servo Wrist (the thing that rotates the board contains the pixels) --> still have to work on Servo AirplaneLauncher (Servo which rotates to release a rubber band, launching the airplane) --> Still have to work on