Build season update 2/18:
Hard stop
We decided that the travel of the gas shock is not sufficient to act as a hardstop, so we added hardstop at the front of the robot. It is also used as the limelight+radio mount for now. The purple part is printed out of TPU to absorb shock.
PDH issues
During testing, our CAN bus ceased receiving traffic, which was traced to the PDH displaying a “Device Overcurrent” blink code and reporting CAN errors on the REV HW client. Despite multiple reboots, errors persisted. Disconnecting the PDH from the CAN bus allowed other devices to function, but reconnecting it resulted in abnormal behavior. REV devices showed normal blink codes but were undetected on the HW client, while CTRE devices displayed “Fault Detected” codes. Vacuuming the PDH for debris and toggling the terminating resistor yielded no change. Proceeding with testing using a spare PDH entails the risk of encountering similar errors, suggesting further investigation into potential causes like electrical issues or component failure.
Testing
Amp scoring
We tried to replicate our prototyping setup on the actual robot during testing. It took us a while to find the correct arm angle and roller speed to get consistent scoring. Once we found them, the amp scoring was very consistent. The arm needs to be kept a certain distance away from the amp so that the note can slide into the amp without getting bent too much. We found an angle where we can run into the amp wall and the arm would have a correct spacing away from the amp to score consistently.
Intake changes
We initially designed funnels to center the gamepiece before entering the tower, but it introduces interference with the tower wire and can not get the gamepiece close to the center enough to fully complete the handoff. We were inspired by team 95’s intake roller design and added two extra rollers to guide the gamepiece to the center of the robot. This solved the centering issue but the handoff is still having some inconsistencies when intaking from the side of the intake, mainly due to the lack of contact with rollers in the tower. The problem will be elaborated further in the drive testing section.
To further reduce the resistance when entering the handoff, we designed another set of rollers at the entrance of the tower.
We will try some other combinations of wheels in the future and see if we can get more control of the gamepiece on the tower side.
Speaker and drive testing
During the testing, we found a very consistent subwoofer speaker shot however, there multiple problems that we ran into during the testing. One of which is the note getting jammed under our intake, probably due to the high compression of our intake and the gap between the lower roller and the framerail. The other was the note getting stuck between our intake and indexer in this scenario, the note was getting pushed down by the bottom roller of our intake. This downward force caused the gp to get lodged between the rollers and the frame rail.
We received another batch of notes recently and noticed that they are a lot stiffer than the original ones and behave quite differently. They are more likely to get stuck in the intake.
Swerve Issues
Disclaimer first - we don’t really know what exactly is going on here, just that something’s wrong.
So far, here’s what we know:
- Not super frequently but occasionally, a swerve motor will oscillate back and forth
- It happens to both drive and turning motors and on both the main and testing robots
- The issues goes away if we power-cycle the robot or redeploy the code
- Last time we tested it, the pivot control also didn’t work correctly while the swerve (drive this time) motor was oscillating, but both were fine after power cycling
Our best theory currently is that there are CAN frames being dropped on initialization that result in bad PIDF setpoint following (none of the SparkMaxes/Flexes have ever acted like this and they all don’t have PIDs running on them). We’re planning on added delays and multiple motor setting calls in code as well as reducing CAN utilization overall, which hopefully will help, but who knows?
Programming
PV Vision Align
Improving on our previous reaction-only vision align command, we tried adding a component that would shift our PID goal based on what the current velocity was, which we thought would give us a not-really-feedforward-but-close-enough-approximation to improve the tracking of the desired gyro heading.
But in testing, we found that “not-really-feedfoward” = very-bad-performance.
We quickly backtracked and added a true feedforward, using current robot velocities to calculate the desired angular velocity at every periodic cycle, which works much better.
(True FF on left, fake on right)
We’re hoping that this will be sufficient for basic shot alignment, as we’re still working on migrating over the oPi + Arducam setup onto the main robot, but we’ll see.
Pivot Control
So it turns out that modeling the voltage necessary to hold the arm stationary against the force generated by gas shocks isn’t the easiest thing to do. The model performed well at low angles, but was obviously wrong at angles close to and past the vertical (the voltage was positive when it should always be negative). For the sake of time, we just ended up using our budget version of REV HC and calling in backup in the form of simple linear regression.
With the two pivot motors in break mode giving us a large margin of error due to static friction, this approximation for how much voltage is needed to keep our arm static has served us quite well so far, although it does mean the arm is difficult to move once the robot is on (RIP drive team people setting up the robot)
After adding on some mostly-theoretical-but-also-half-tuned kV values, a nice eyeballed proportional gain of two, and some motion profiles, our pivot control graph looks like this.
We will take some time to crank up the arm speed later - for now, this is satisfactory.