3839 FTC ROBOTICS DECODE 25-26

Last devlog…

1. Didn’t make it to states but we had a top 4 autonomous in our league and a 96th percentile for autonomous, which relies completely on programming
2. I made custom teleops (user-controlled robot movement section of the matches) for each spot the robot ends up so that with ONE click of the button the robot automatically moves to the shooting position and auto-aims
3. Fixed autonomous points so in the end we got around 8-11 per match
4. Added encoders to wheel and intake motors, allowing for setVelocity to be used instead of setPower, making it more consistent
5. Overloaded shooting methods to make it more clean a while ago, this devlog includes multiple days of work
6. Ended up not using the pid tuners for the shotmotors since I ran out of time and each time I tried to tune it the motor would overheat and start burning :/
   I forgot to record the competition footage so here are some older clips between devlogs….

If you’re curious about which files (auto and teleop) I actually used for comp, its the simple autos and then the ones named BackTele FrontTele s so I made an auto and teleop for each position on the field

1. Rebuilt the entire ramp where the balls go since I need it to be looser
2. Adjust the outtake() Method for the balls so now the shot motors slow down slightly and the intake and wheel motors also slightly slow down afterwards to even out the velocities between the first and the second ’n third.
3. Adjusted power
4. Note: Need to add encoders for intake and wheel

also I couldn’t upload the 29 second video too large here are some screenshots I guess

finally achieved 9 ball auto

1. Added pid tuner for the shotmotors
2. Organized code into classes
3. Tried to tune the shotmotors to the same velocity to have a more consistent outtake of the artifacts

Continued to work on auto–>Best record I got was 5 balls out of 9 shot

1. I worked on plotting the points
2. Added velocity and set rpm-based stuff to make shooters more consistent–>Helped a little bit but failed to solve the whole issue
3. I fixed many of the following path parts cause it was bugging out and the robot started tweaking
4. We found that static electricity would sometimes impact our robot
   (ignore the person’s voice in the vid)

Notes: Even though time was shorter, I was accomplish a lot
Changes:

1. Now the pedropathing works slightly better even though the total heading is still off–>Can complete one cycle, picking up three balls and actually getting one ball into the goal.
2. I was able to turn ONE COMPLETE CYCLE into a method, dramatically reducing the amount of code for the actual autonomousupdate() part and even though the entire class is bulky, I reoganized it so it should make more sense.
3. I changed the direction of the pinpoint 180 degrees, so the robot would finally recognize positive coordinate numbers as it should
4. I started using setVelocity as opposed to setPower because it will work better to get more consistent shooting for the future–>TBD if it actually works

A LOT OF hours logged today

Recap:

1. First hour to two hours I completely rewrote autonomous class
   I. Split autonomous into different methods instead of one big switch function with functions Onecycle() and made it so that the main autonomous
   (I accidentally added some old images, but the new images about autonomousPathUpdate() and Onecycle() should be there too
   II. Even though I wrote it, the pedropathing/localization of the robot was off, so we never got to know if this code worked since something went wrong with the coordinate system–>On panels it was like weirdly reverse and reflected–>When the robot moved up and down in the field panels would show it moving side to side
2. For the next 3-4 hours I worked on trying to fix the pedropathing problem with a couple buddies from robotics. I have a hunch that something physical about the pinpoint and swing arm is wrong, but I couldn’t quite find anything to condemn the builders about. We tried reversing the offsets, encoders, and anything else, but never got panels and pedropathing to work the way it was normally supposed to…We might have to just deal with it and find the coordinates with the panels messed up. Even this is difficult as the values from the localization test do not match up with the values we want and should be using (pedropathing uses a specific coordinate test while the localization test that allows people to drive around and test the x and y increasing set the inital point as 0, 0)

The main problem after today’s session is that the coordinates we found on pedropathing visualizer are PHYSICALLY not on the field as shown on panels and we see NEGATIVE coordinate values of the robot on the driver station. SMH

Ts is so fried bro league championships is in two weeks.

Finally finished installing pedropathing! That took so long -_-

Pedropathing is a program that tracks specific points on a map and continuously adjusts the robot to that specific point and heading.
Basically, you plot the points you want the robots to goto and draw a line between them, which will become the path the robot will take.

Adjusted robot power of motors as well as writing basic autonomous took a long ahh time

Switched the reversal of some motors and started planning my autonomous robot path through pedropathing visualizer: https://visualizer.pedropathing.com/

Worked on tuning the robot–>Got through the localization test and getting the offsets…for actually tuning the pidfs I got through the translational (the first one)

https://github.com/Chingwonding/3839/tree/Tapfuma/TeamCode