This week, mechanical team assembled and attached our amp mechanism to the robot, and finished attaching the shooter to the robot. We have cracks forming in the indexer polycarb, which we think might be caused by forces from either the corner of the gearbox on the plate, or hammering on the hex shaft connected to the indexer plates. We drilled holes at the end of the major cracks to hopefully keep them from spreading.
Design has been working on and off on actual CAD and mostly helping with other parts of the process. One notable aspect of our design work recently has been our button box. This year, we have migrated to a custom 3D printed panel approach, using a special layout with regards to the robot function. Using 3 light-up buttons, 1 regular button, 3 LEDs, 3 dials, and 2 heavy switches, we have covered not only the nominal robot function but also a number of system overrides. By switching color partway through the print, we will have a high-contrast control panel that not only looks awesome but allows for quick, intuitive operation. It was primarily constructed out of electrical components scrounged out of derelict cabinets, and used a fantastic assortment of different potentiometers with 3D printed dials affixed to the spindle.
For vision, we are currently trying to get a second camera hooked up to our Pi 5. The front-facing camera is currently accurate, and we can get all kinds of information about field positioning from it but not from the back-facing camera, which would double how much of the field we can see and make it so we are basically never out of sight of the April tags and be able to know where we are at all times. We also are adding functionality to our code so we can turn to face any of the April tags which we know we will need and will make driving it substantially easier. This week, we finished wiring the robot, setting CAN IDs to all SparkMAXes, and updating firmware to all devices. We used Rev Hardware Client to make sure CAN was working, and there were no conflicting CAN IDs. We also used Rev Hardware Client to individually run our shooter motors and test shooting. We attached an infrared beam break between our indexer and our shooter to be able to tell when a note is ready. We have continued using 3/4” conduit on the wire and encoder cable bundles between the SparkMAXes and NEO motors. We have dealt with a few issues: our radio was disconnecting occasionally and briefly, so we decided to use the Rev Radio Power Module instead of our POE injector, and this appears to have solved the issue. Software is also dealing with not being able to reverse the encoder direction when using firmware PID in the SparkMAXes, so we have attempted to address this issue by replacing the encoders with those from a previous test robot, on which they were working. Our encoders were disconnecting occasionally, so we zip-tied our encoder ribbon cables to the SparkMAXes and swerve modules in such a way that it made the plug connections more secure. We connected our Raspberry Pi 5 for vision to power supply over a mangled USB-C cable powered from a 12V to 5V buck converter brick. We began running Ethernet connections through a network switch so that we could connect the Pi over Ethernet. We are using a NEO 550 to rotate into place and retract a redirect guard to allow our shooter to score in the amp. There was a CAN disconnect issue where a stretched CAN cable unplugged from a SparkMAX, disconnecting downstream motor controllers as well (the connection was not looped over). We created a small test circuit that intercedes between the beam break and the RoboRIO and lights up when the beam break is tripped; this allows us to eliminate hardware issues with the beam break.
Scrimmage put our robot through several (unintentional) stress tests, which revealed many interesting failing points of the robot. First and foremost, not all connections were secure. One of the ways this manifested itself was through the disconnect of one of the motor wires to the drive NEO in the front left swerve module. Interestingly enough, we now know based on this that NEOs can run with just 1 stage of the coil timing cycle, as the motor was still able to run if it was kickstarted, which made it hard to pinpoint the problem as the motor appeared to be in somewhat-working condition. Another known issue, even before scrimmage, is that our encoder connections to the SparkMAXes are unreliable. We have tried to remedy this by tying down the encoder ribbon cables. While working on the robot in the pit, an encoder ribbon cable got pinched, breaking the power connection. Unfortunately, this was one of the few things that we did not pack in our tool cart. We were able to fix this by peeling away the ribbon cable wire from the rest, stripping both ends, and connecting them with a Wago lever nut, which lasted the entire day without any problems. A continued issue we are running into is the radio momentarily disconnecting. As of now, we are not sure whether this is a product of signal interference or weak signal, brownouts in the power supply, or a poorly functioning radio. We will work on determining the problem, including trying a redundant power supply. An interesting thing that happened was when the robot (accidentally) ran full power into the wall at the edge of the field. Apparently, the stall current the motors drew was enough to cause global brownouts to the robot, actually restarting the robot. A very large and simple mistake we made was that we forgot to calibrate the NavX, which cost us our first match (we were essentially unable to move without spinning). We also learned a significant amount from our optional inspection. Simple issues include having exposed breaker terminals, the inspector not being able to verify the AWG of our power wires, zip ties needing to be trimmed, and exposed bolt heads around the battery need to be covered. Interestingly, the clip we used on our battery strap was designed to be break-away to prevent choking, but this means that it is not suitable for the robot.
We opted initially for a single AndyMark climber instead of two. Because the climber is mounted on the frame rail, the robot tilts significantly when we attempt to climb. The climber also does not retract low enough to climb on the lowest point of the chain. Because the climber was off center we could only climb while the bumpers were supported by the podium. This means we can only climb on the highest part of the chain on one side. We now plan to attach another AndyMark climber to the other side of the robot so that we can climb on both sides, however this does not solve the issue of climbing on the lowest point of the chain.
The robot drive base code, having been recently updated, now handles far smoother with much more accurate movement than it had done in the past. However, the drivers are still acclimating to the heading-position joystick control scheme. While most video games use control based on rotational velocity, this system utilizes the position of the steering-joystick to determine the heading of the robot. One issue that has arisen from this is that rotation is reversed based on the side of interest of the robot. For instance, when targeting a game piece, the “front” of the robot (side of interest) is the intake. But when launching said game piece, the rear-mounted launcher is the side of interest. Because our steering system considers the intake to be the front, steering feels “backwards” when shooting, which can lead to missed shots. The intake and shooter have mostly been functioning adequately. The intake currently has an issue when a game piece becomes jammed after intaking from the far sides of the intake. When we intook a note, it got caught on our amp mechanism and the mounts for our sponsor panel, which prevented it from touching the indexer and fully making its way into the robot. We are currently still deciding on how we plan to fix this. The shooter, while currently working, has required some troubleshooting before we were able to bring it to its full potential. The handoff between the indexer and the shooter has been faulty, and the indexer has been required to run at full speed in order to allow the shooter to fire unimpeded. While we were able to fix this issue with software, we have other plans to increase the moment of inertia in the flywheels, so that a smaller percentage of the kinetic energy is removed by the handoff. This would be achieved by filling the wheels with epoxy, or making them out of a heavier material.
