Hey guys, really big fan of your thorough posts so far! What’s the material of your horizontal feeder roller? Also, I remember really liking your driver station at the Del Mar Fair event last year; would you guys be willing to share the CAD for it?
1 Like
Same as JITB Roller material from 2023 Robot.
4 Likes
We don’t have driver station CAD. Our driver station for 2022-23 was an AndyMark driver station tray. We added a platform in the middle for the laptop, elevated off the tray so we can fit cables, power bricks, etc. under it. The Xbox holder is just something off of Thingiverse IIRC. For 2023, we mounted a 7” touchscreen on the right side using 80/20 to raise it and some scrap plastic to make a frame.
3 Likes
When you say to use a threshold for the pitch, wdym, can you show us a snippet of the code?
Sure! Note that we sorted by Lowest, so the “best” target is the one with the lowest value for pitch. PhotonLib reports pitch in degrees here.
// Determine if the latest camera result has any actual targets.
// Further filtering could be added here.
public boolean hasTarget() {
if (result == null) return false;
if (!result.hasTargets()) return false;
if (result.getBestTarget().getPitch() > 3) return false;
return true;
}
// Also filter when operating on the whole targets list
var list = result.getTargets().removeIf((t)-> (t.getPitch() > 3));
Perfect, thank you so much. Also, could you happen to send maybe a SS or an image of how you configured your photonvision for note detection?
For machine learning or for colored shape pipelines?
For colored shape pipeline
Late post, but it’s our progress from weeks 2 and 3 all rolled into one!
Mechanical
Shortly after our previous post, we received our 0.073” steel bellypan from Fabworks. We got right to work taking off our MK4i modules from our off-season drivebase, inspecting them, greasing them, and then assembling our 2024 drivebase. Our final drivebase size ended up being 25.5” x 25.5”. This is about the same size as last year’s robot, but wiring on this one is going to be a bigger challenge.
To make wiring easier, we designed in many cable pass-throughs in our structural 2”x1” drivebase cross members, as well as our plate that holds our flipped PDH and our RoboRio. After manufacturing these on our CNC, we deburred them to make sure wires wouldn’t get cut, as well as installing some 3d printed bridge pieces to give the wires an even smoother transition. These cable pass-throughs have already been super helpful to us for temporarily wiring everything in.
After we had our temporary wiring in, we handed the 2024 drivebase over to software. Mechanical then started work on disassembling last year’s robot to salvage ThriftyBot elevator blocks for this year’s climber.
Software
Drivetrain
We had a few issues with getting the drivetrain going:
-
The drive motor SPARK Flexes had a firmware update that required entering recovery mode. With the SDS MK4i drive motor mounting, the Flex mode button is blocked by a standoff, so we needed to take the motors out of the gearbox. Because we didn’t want to disconnect the controllers from the wiring harness, updating these became a two-person job, one holding the motor and pressing the button, and the other connecting it to the hardware client at the right time. The actual recovery-mode update experience went smoothly though.
-
We had significant trouble making the steer PID work. We do our PID directly on the Spark MAX with Redux Helium Canandcoders as a feedback sensor. In adapting our MK4 code to the MK4is, we knew we had to invert the steering motor. However, in our case, we also had to set the absolute encoder to be inverted relative to the steering motor, so that the PID would work correctly and not oscillate violently around the wraparound point.
After those issues were fixed, the drivebase runs well:
Vision
Good pose estimation will be critical to our controls goals this year. Like last year, we intend to have four AprilTag cameras, this time running on two Orange Pi 5 coprocessors. We will also have an additional color global shutter camera for ML note detection, which will run on one of those two processors. Because most of the ML work is done on the special-purpose hardware in the Orange Pi, additional CPU overhead is minimal.
We plan to put our cameras on a crossbar between the two climbers on either side of the robot. The crossbar in the photo below is about the height that our cameras in our final bot would be mounted at.
Starting with the one camera seen above, we measured its position and set up pose estimation. Much of this was the same as last season, though we refactored the vision code so it was not directly in the drivebase subsystem. We’re also using PhotonVision’s on-coprocessor multi-tag estimation, which takes a significant processing load off the RIO. Our vision system will need some tuning, but given just two speaker tags, the robot was able to estimate its position from most locations we would use for shooting.
CAD
While mechanical has been working on building and wiring the drivebase, CAD has been hard at work finalizing our subsystems. We had a pretty big change in scope between our week 2 and week 3 workshops. After seeing all the testing other teams like 3255, 900, and 111 have done trying to shoot into the trap, we decided that this would be a great strategy to implement. Even if our design ends up being 50% accurate, the ability to just pick the note up, align with AprilTags, and shoot again is huge.
Our best previous design to score in the trap involved an elevator with latching hooks that would allow us to climb up high without impacting our ability to go under the stage. On the top of this elevator, we would have a manipulator with rollers, fed by our intake, which would push open the trap and shoot the piece downward and in. This might still be our upgrade for later-week competitions or off season events if shooting into trap is too inaccurate.
Making the decision to scale down our trap score / climb subsystem into just a quick climb system means that we can speed up development time, and get mechanical and electrical finished sooner. This will allow us to give the robot over to software much sooner for testing and to drive team for diver practice. It also means that we can make the sides of the climber independent, to help the robot hang more level on the ends of the chain.
CAD on the shooter is going strong. We decided on a horizontal shooting configuration using 3” straight flex wheels pushed over dead axle tubing, with two Vortex motors powering the whole system. This shooter system also has a pivot to allow us to adjust our angle to shoot at further ranges.
Intake CAD was at a point at our most recent workshop where we could start fabricating everything out of polycarb. We didn’t prototype anything for intake this year yet, so we are thinking of this designed polycarb one as our intake.
While there are still some small improvements to be made, this intake prototype has worked great for us so far. With this out of the way, we can now get to work on our “midtake” subsystem which will allow us to funnel and store the gamepiece for quick shooting.
Business
This past week, the business team learned how to use our new BambuLab 3D printer. As a practice project, they chose this flexible print-in-place scorpion. The large model turned out well, so they printed several smaller versions, which might become judges’ gifts this year. Business has also been working on team shirt designs for this season.
14 Likes
Hello, I really like your Intake design, is your CAD public?
Great work!
We don’t share our CAD until after competition, but if you’re asking about the roller design, I’ll see if we can share a cross-section screenshot. It’s a design inspired by the dead-axle rollers used by 2910.
I can’t really see, is there something on the intake (like a panel) that is deflecting the piece up? If not did you have an issues with it going in the gap between the bottom and top rollers of the intake.
It’s not often an issue but we do plan to put guide panels on top and bottom.
Thanks! As said above our cad isn’t public yet but we don’t mind sharing some screenshots of what we have been working on. Here’s a view of the main assembly and below is a cross-section.
5 Likes
Thanks for sharing!
I have a couple of questions in particular about the rollers.
I can see you have a dead axle, how does the pulley attaches to the roller?
Does it has a bearing between the dead axle and the roller/pulley?
Are the tubes the 2" polycarbonate tubes from Mcmaster?
Great work guys, thanks!
The pulley is a 3d print, slight press fit on the polycarb tubing (1.5” OD), and held in place by super glue. We tried to remove one from the tubing with a dead blow hammer yesterday and couldn’t so we think this should hold up great in competition. The dead axle is from REV, and it’s paired with their 0.75” ID needle bearings which we pressed into the 3d printed pulley parts. Hope this helps!
1 Like
Quite a bit of progress has been made since our last OA post! We decided not to post last week and roll it into this week’s update because we had some design setbacks. Because this post will be quite large, we will be covering each subsystem’s progress individually, from our last post up to its current state. This will mean that some photos are out of chronological order, you have been warned.
Drivebase
Wiring this drivebase has been quite a pain. We have been kicking ourselves for choosing 25.5”x25.5” for robot perimeter for a while now. Because of this, we decided to upgrade our drive and steer motors on mk4i to use Vortexes and Flexes so we didn’t have to find areas to package Spark MAX’s. This came with a couple of challenges. Because we are running Helium Canandcoders, we wanted to run the 10-pin cable for finding initial offsets on steering. We used these 10-pin cables and mag encoders last year, and we didn’t like the thought of higher CAN network utilization.
Our biggest problem with trying to implement the Canandcoders into our Vortex motors was the availability of cables that plug into the new data port that the Flex controllers have. Just last week REV released cables for this, but when we were working on this solution a few weeks ago we made a rush order to Digikey to get driving ASAP. Unfortunately, the gauge of these wires was too large to work for direct bump connecter installation, so we went to our fallback plan of using Gadgeteer breakout boards. Our early version is printed in green PLA CF and our final version is printed in black PLA CF.
The TigerEye cable connects right into a Gadgeteer Breakout Board, which then feeds into standard 10-pin connectors which were cut to length and attached into the Canandcoder. By connecting the breakout board into the 3d print that holds the standoffs for the mk4i we got a sturdy mounting location that won’t get disconnected. This solution also means 4 fewer CAN wires and 2 fewer power wires per module to cable manage compared to if we used the Canandcoders in CAN mode.
With most of our wiring out of the way, our removable panel for our PDH and the cable pass throughs on our main cross tubes have been lifesavers for us. We still probably spent 100+ man hours on wiring this robot, but having easy ways to route power, CAN, and ethernet wires all around made the process go much smoother.
Intake
Thankfully our intake did not need any major modifications compared to what was seen in our last post. The main structure consists of black polycarbonate side panels with Rev’s dead axle system supporting 1.5” OD, 1/16” wall polycarbonate tubes with 50a rubber air hose stretched over top. We first tested this system in our 2023 off-season when we replicated 2910’s hand onto our 2023 in-season bot. On the first day of this build season, we tried picking up notes with this robot and decided that this would be a great approach for picking up notes.
A few minor changes have been made to the intake design since last post. The first change we made was making the outer plates for the intake pivot out of ¼” aluminum to increase strength and rigidity. A cross shaft of ½” thunderhex was added between the two sides to reinforce the intake further. While this might have been a bit of overbuilding, it allowed us to easily disassemble the intake from our drivebase quite a few times as we tried to figure out the wiring.
The second change we made was getting rid of the last intake roller , which was messing up the transition from intake to midtake in our robot. It was making the notes fly up when they jumped the gap between these two subsystems which led to jams. Having one less roller is also nice from a complexity and ease of repair standpoint. Along the same lines, we removed the second Neo motor we had powering the intake rollers as we felt that it was already plenty strong enough. Two motors was hurting performance, since the intake was forcing notes into the midtake instead of the midtake pulling notes out of the intake.
Our third change to this system was to find a way to funnel the note into the middle of our intake. Our intake is 22.5” wide and the next subsystem in line, the midtake, is 16”. The solution to this turned out to be a low infill 3d printed ramp which has done a great job of funneling so far.
With all these changes made, the intake is pretty much competition ready. We even have a complete spare ready to drop in, which is something we haven’t really done before.
Midtake
The midtake is what we call the funneling and gamepiece holding subsystem right after the intake. There were a few major revisions of this assembly, which were mainly to add large 3d prints to round out corners where the notes would hit, or to add places to mount electronics.
Our first design consisted of two NEO motors each running a separate dead axle roller assembly just like our intake. 3d prints were used to mount the black polycarb dead axle and Neo plates to the bottom baseplate which was made out of black ABS plastic. We found that polycarbonate was way to grippy for notes, but ABS was quite smooth. While there were a few issues with this design, like sharp corners and too much note compression, it was still functional so we gave it to software to test things out.
From a software perspective, the main challenge with the midtake is receiving the note from the intake and stopping it before it gets fully to the shooter. At the speeds the intake is running, the note enters the midtake and would be past the front roller in less than a quarter of a second. We first tried current-spike detection on the front roller. We had a few consistency issues with this.
-
The initial current spike from starting the roller needed to be ignored.
-
Notes getting stuck while being funneled into the intake would stop the rollers early.
-
Sometimes the note would not cause enough of a current spike to be detected.
-
A wiring issue in that iteration of the midtake caused the back roller’s Spark MAX to power-cycle sometimes when the note went through. Though not tied to the current-sensing approach directly, this was another way notes could get stuck.
It became clear that what we really needed was a way to detect when the note was under the front roller, not just when the roller was trying to push it. We installed the Playing With Fusion CAN time-of-flight sensor, a distance sensor looking across the midtake under the front roller. Our algorithm now is:
- Deploy and spin the intake. Run the midtake at high speed (matching intake speed) until the TOF detects a note.
- Deploy and spin the intake. Run the midtake at a slower speed until the TOF no longer detects a note.
- Raise the intake, stop the intake rollers, and reverse the midtake until the TOF detects the note again (or until timeout)
The three sub-commands of the last step are individually broken out of the main command group using ScheduleCommand. We did this because we want the intake to continue to raise if the midtake part is interrupted by some other use for it.
Now knowing what we needed to change, we worked on a final CAD design that had a separate plate to mount 4 spark max’s for intake and shooter, as well as an integrated spot for the Time of Flight sensor from PWF. This is what the final design looked like.
Shooter
The shooter subsystem has seen the most major CAD revisions by far, out of all of our systems. Our current one is version four, and we are still making minor tweaks to this design. The reason we had to redesign so many times was down to fitting the shooter around other subsystems, in addition to wanting to nail the shooter build first try. Our general design would consist of 2 Vortex motors powering individual dead axle shafts with 3” wheels. We would also have one Neo powering angle adjust and another Neo powering a set of feeder rollers.
One observation we made in our early shooter testing was that the feeder rollers’ speed could significantly affect the shot. We thought this might be because the velocity of the shooter wheels was easily 4x the velocity of the shooter rollers. After brainstorming this, we came up with 3 ways to solve this. First was to place the feeder rollers one note’s distance away from the shooter rollers, the second was to make the feeder rollers have the same speed as the shooter rollers, and our third and preferred option was to make the shooter rollers able to push one way but slip in the other.
Our early prototype of this included WCP’s ratchet plate integrated directly into a 3d print that powered a roller. The benefit of this was clear. It would drive the note into the shooter wheels with good torque, and then when the shooter wheels grabbed the note, the ratchet mechanism would allow the note to be pulled at higher speed from the feeder rollers. Our final mechanism was created out of a one-way sprag clutch bearing that fit around a ⅜” ground shaft, which would also act as our shooter pivot. This was then implemented into a combined gear reverser and dead axle driver that allowed us to drive both feeder rollers at once.
The main shooter wheel and drive portion of our shooter has had plenty of revisions as well. We started out with 3” straight flex wheels from VP, since at the time of purchase, our preferred option of 3” max spline compliant wheels were out of stock. These wheels with their 1” ID were just press fit over the 1.25” aluminum tube. We started out with the 45a straight flex wheels, which we quickly realized wouldn’t work. Above 3000 rpm the wheels expanded enough to come off of the aluminum drive tube and wander about.
We tried the 60a wheels right after this which also had the same issues, so we made a quick revision to max spline and 3” REV compliant wheels like we originally planned to do. So far this looks extremely promising. The last issue that we are currently working to correct is trying to get more velocity on our shooter wheels. We chose 3” wheels to reduce the size of the assembly, but this meant we had to use 11 volts to get the right velocity. Many other teams are running 4” wheels at 1:1 ratios, which we should have probably gone with.
Our currently untested solution to the velocity problem is to run with a speed increase on our belt pulleys. In our testing we were running 1:1 with a 28t pulley on the Vortex motor and a 28t pulley on the Max Spline. This next weekend we are going to try a 43t pulley on vortex to a 26t pulley on the Max Spline. Thankfully we have the HTD belts in stock for this, and the C2C is only off by 4 thou. Hopefully this gets us the speed increase we need.
Another area we are still working on in the shooter assembly is the gear racks which drive the shooter angle. Currently these are 3d prints which are longer than our pivot range. The hope for these is to iterate with 3d prints until we are happy with the design, adding hard stops into the extremes in the process to give us solid areas to zero out on. The current lower hard stop is the shooter wheels resting on the swerve modules, and this means we can’t spin the shooter wheels without first raising the pivot. Our current upper hard stop is the shooter hitting the climber risers. While this doesn’t hurt anything, we do need to shoot with the pivot all the way up for our close shots, so we can’t limit the pivot too much more. Once we design hard stops, we plan to machine these gear racks out of ⅜” aluminum.
Climber
Our last subsystem is our climber. The design consists of independent climb modules either side, powered by 25:1 Max Planetary gearboxes and driven by a Vortex motor for packaging. The linear bearing system we used was comprised of back to back TTB elevator blocks. We had used these in our last year’s robot and loved them, so we decided to use them again. By putting them back to back, we could make two mini elevators on either side, which also got rid of a moving center lower support frame which would go through the middle of our robot.
After completing this assembly off the robot, it was pretty easy to slot in, wire up, and program. At last weekend’s workshop, we demonstrated our first climb! In these climbs we are running very slow for safety’s sake, with current limit capped below 15 amps and at 1 volt per side. We had some good results with side climb too.
Thankfully climb looks like it will be our one system that doesn’t need iteration. The last task we have ahead of us with this subassembly is mounting a sponsor panel below the top C channel. Behind this panel we plan to mount all our vision processing hardware, Brainbox ethernet switch, and radio. On top of this C channel we have mounted what we are calling the crown. This 3d print will house 5 global shutter cameras for AprilTag detection. We also have an additional color global shutter camera below the top bar that we will be using for ML note detection using PhotonVision.
To process all this incoming camera data, we worked on a way to compact the 3 OrangePi 5’s we would be using. After an iteration or two, we ended up with the case below. The case height is right at 2” so it will fit in place. Power is given to each OPI5 through a Pololu step down step up converter.
Whole Robot
Now that the robot is 90% complete, mechanical and CAD subteams can take a back seat and allow programming to take the reins. Ideally, we would have liked to be at this stage two weeks ago, but we had some setbacks in the design of the shooter and midtake. These systems are critical for us to nail first time, as we didn’t want to build it all and then find out the big issues. Because of this, we decided to push the build back a week.
Even with some setbacks, we feel we are making some great progress so far. We now have a robot that we know can quick climb, our electronics are 95% finished, and the intake and midtake have both been working solid so far. The shooter looks promising, and with a speed increase, we hope to be making edge of wing shots. That about wraps up the mechanical and CAD team’s progress, stay tuned for a software update next!
14 Likes
Long awaited programming post! Our team has been very busy the past few weeks. Here is the progress we made before our first competition at the Ventura County Regional. We will have a second post after this one for post-Ventura topics and changes.
Software Features for Ventura
For our first competition, we focused on a few main control features to assist the drivers.
Automatic Shooter Aiming
Our hope for shooting is that the robot will be ready to feed the note into the shooter as soon as the drivetrain stops. To that end, we wanted the robot to adapt to its current position. The shooter pivot is always maintaining the correct angle for a shot, except when amp scoring. We choose its goal using WPILib’s InterpolatingDoubleTreeMap, where we map distance to shooter angle. We have similar maps from distance to shooter wheel speed.
While we could have combined these maps into one map that interpolates between ShotParameter objects according to distance, the maps are mostly independent, besides having their data points at the same tuned distances. We kept these as three separate maps, but with a utility method that specifies a distance, angle, and wheel speeds so that each tuned shot distance is stored in a single line in our code.
Drivetrain Aiming
With our “crown” of cameras providing pose estimation across the field, we bound most of the buttons on the driver controller to various heading locks. The X, Y, and B buttons face the various climber chains. This triangle of buttons matches the triangle of positions where a climbing robot would be. X is for the left chain, Y is for the center, and B is for the right chain. The A button uses our note-detection camera to face the nearest note. Unfortunately, due to a PhotonVision issue that was not fixed in time for Ventura, we didn’t use object detection for this event.
The driver’s right trigger faces the speaker. Since this desired angle changes over time, we calculated the derivative of facing angle based on the robot’s current velocity, which helps us keep up with the target.
The driver’s left trigger automatically drives to the amp. This is the only actual automatic driving. The other buttons leave translational control up to the joysticks. Our amp align uses PathPlanner’s on-the-fly path generation, but not the obstacle-avoiding pathfinding algorithm, which we found to produce poor results so close to the field wall. The driver therefore needs to only activate the amp align with a clear line-of-drive to the amp. This is not a major issue, given the typical layout of defense and the otherwise open corner of the field. Our amp shot was not very consistent even with alignment, but the button is there pending later improvements.
The last drivetrain aim button is actually on the operator controller. It faces the alliance wall and spins up and aims the shooter according to the distance perpendicular to the wall, not to the speaker. The hope was that this would allow drive-by shots, but the speaker corner is rarely undefended enough to try it.
Intake+Index Automation
The last main piece of driver assistance is the automatic intake retraction and indexing routine. This uses a Playing With Fusion Time-of-Flight distance sensor mounted under the front midtake roller. Our routine has three steps:
-
Deploy and spin the intake fast, while also spinning the midtake and feeder rollers. Do this until the TOF sensor detects a note entering the midtake.
-
Continue spinning all rollers at a slower speed until the TOF sensor no longer detects a note.
-
Schedule the following three commands individually, interrupting the main routine, but allowing individual commands to be interrupted:
- Retract the intake
- reverse the midtake until the TOF detects the note again
- Spin the intake rollers slowly for a second or so more, then stop them
Autonomous
We developed two main autonomous routines for Ventura. In general, our hope for structuring our code is that autonomous routines can use the same superstructure commands the driver does, but on an optimal and repeatable drivetrain path. This was mostly achieved, in that the shooter pivot and wheels do their regular spin-up and aim commands, and for midline notes, we run the above intake routine while going out for the note pickup.
4 Note Close
Our 4-Note auto starts on the center face of the subwoofer and scores the preload and the three close notes. Because of the way our note path is set up, we can simply run the intake, midtake, and shooters at full speed, and intake and shoot the notes as fast as they can be pulled through the robot. For Ventura, we had some cases where the notes would not go through as quickly as expected, for various reasons, so we added pauses after each pickup to avoid controlling two notes at once.
3 Note Midline
If we wanted to get picked at Ventura, we knew our auto options would need to complement our alliance partners, and most teams would focus on the three close notes. We developed a routine that shot the preload and went for the two midline notes on the source side. This stays out of the way of our partners. For this routine, we used the teleop intake command when going for the midline notes. We use Choreo path splitting at stop points to break our path into segments. We split at shooting positions, not at intake positions. This allows us to generalize our auto routines into “drive this path while intaking”/”feed to shooter”/repeat. Though we only had one routine that used this generalization, it was helpful to confirm that autonomous cycles could be that generic and path-independent, which gave us more confidence in developing new routines.
Custom Driver Dashboard
Like last year, we developed a custom driver dashboard for this robot. Unlike last year, this one could have been easily replicated in a program like Elastic. However, we went with the custom route since it was easy to modify last year’s dashboard, and it avoided the risk of losing or changing the layout.
The dashboard has a few main sections.
The row of five indicators at the top are all conditions needed for making a shot. If the top row is all green, the shot is ready to go. From left to right, these conditions are:
- Does the TOF sensor detect a note?
- Is the robot within the tuned distance range based on the shooter aiming maps?
- Is the robot facing angle close enough to the speaker to make the shot?
- Is the shooter pivot close enough to its goal? (as we tuned the shooter pivot more, this turned out to be effectively always true)
- Are the shooter wheels close enough to the desired speed?
On the next row down, we have an indicator that the note detection sees a note. (Since we didn’t use note detection for Ventura, this indicator was not very useful.) If this is false, the face-note button will also rumble the driver controller when pressed. The auto chooser is in the center of the screen on this row.
Below the sees-note indicator, four boxes show dashboard connection status, driver and operator controller connection status, and whether or not the intake has been homed, which is done by manually bringing the intake to its fully retracted stop (its starting configuration) and pressing the driver Start button.
In the center of the screen is a match timer. This turns yellow at the 25 second mark as a reminder to the drivers to stay away from the other alliance’s stage.
On the right side, the drivers can see the intake camera, which is (ideally) used for note detection. Because the electronics panel between the climbers blocks the view of the intake, this camera is important for cross-field driving even when note detection is not in use.
Ventura Mechanical Changes
Since our last post, we finished working on the top electronics bay to make us competition-ready. This top panel needed to be lightweight but also house all our electronics. We also had our main shutoff switch here below the camera bar. Our choice for structure was 1/16” black polycarbonate panels attached to the robot with super thin PLA CF 3d prints. When assembled, the structure is surprisingly rigid.
We had a bunch of electronics to put up here. The biggest part was our custom Orange Pi 5 case which housed 3 Pololu buck booster converters and 3 Orange Pi’s sandwiched together. Above this, we had a mini power module that provided power for the buck boosters and the Brainbox ethernet switch. We also had a radio power module and bundles of camera wires for our 6 cameras.
On top of the camera bar, we mounted our radio. We had some concerns about notes getting stuck over the climber tops which couldn’t be removed in a match. To fix this we CNCed a small deflector top piece which spanned the distance from the climbers to the middle camera assembly, providing a smooth top surface that notes bounced off of. With this, we were no longer worried about a note getting stuck inside our robot anywhere.
Another preventative change we made before the competition was version two of our intake-centering ramps. Our previous version had just been two, 30-degree ramps that matched the profile of the intake rollers. As our intake took 60-80 amps to intake a brand new note, we wanted to change the ramp profile to make it easier to slide across. The solution we came up with (dubbed the rollerblade) is 6, 0.75” OD Delrin spacers in a row, supported by #10-32 grub screws attached into the ramp pieces. These significantly decreased the friction in the intake without increasing the weight.
With all these changes, we loaded up the robot for Ventura…
13 Likes
Ventura Recap
We had plenty of issues in our qualifier matches at Ventura, but we still had a blast. Fortunately, we managed to fix most of the problems by our final qual match. Despite the issues we had, we pulled through and were the first pick of team 5817 Uni-Rex, the 5th alliance captain. In playoff matches, we were operating at full strength. After a whirlwind of matches, us, Uni-Rex, and team 589 Falkon Robotics managed to make it to the finals! We are super happy with how our robot performed in the playoffs.
Post-Ventura Improvements
Since the competition, we have changed quite a few things on our robot. We were rewiring electronics, changing up the shooter, trying new autos, and even adding in a new subsystem for amp scoring.
Comms Network Issues
One of the first things we did in our post-Ventura workshop was to test how we were getting disconnects and then completely rewire our problematic comms network. While we thought we found and fixed an issue on our network in the regional, we were still having the micro disconnect issue even after we swapped ethernet switches, power supplies, and ethernet cables.
What we found in our testing is that we seemed to have a bad Radio Power Module. We swapped to using a barrel jack connector and VRM to simplify the network. Additionally, we pared down how many cameras we were using for April tag vision, so we could take two Orange Pi 5’s out of the network to simplify things. With these changes, we have a more robust network.
Intake Centering
At Ventura, we often got notes stuck in the intake that would not be centered properly. This often resulted in cycles where we’d have to spit the note out of the retracted intake and pick it up more centered. Upon later closer inspection, we noticed that the two leading rollers would grab the note before it hit the centering wedges. Adding a wrap of tape to reduce the grip at the ends of these rollers helped with centering more consistently. KISS rule is in effect here.
Shooter Changes
A big change we made since Ventura was to our shooter. We had problems shooting from more than 5 feet away from the subwoofer, as the notes would tumble and behave weirdly. Ideally, we would want to shoot from the protected zone by the stage, or even from further out if possible to make our cycles as quick as they could be. Our shooter arrangement at this point consisted of two max spline shafts, one top and one bottom, each powered 1:1.65 speed increase to 3-inch MaxSpline Grip wheels. We had sets of 3 wheels in every corner of our shooter. The compliant wheels shown in previous posts had already been replaced before Ventura, because their variable expansion was providing inconsistent compression and variety in shots.
This setup powered the note evenly, but the flight was not straight at all. It would flop the moment it left the shooter, often making a half-turn end-over-end even on subwoofer shots. This meant that we had to shoot most our shots pressed up against the subwoofer, which made us prime targets for being defended. We tried varying the top and bottom roller speeds, but this didn’t really make a consistent improvement, and often just caused flopping the other direction. While looking for a solution to our issue, we saw that many other teams were using spin to stabilize the note. To test if this would work for us, we decided to try what teams like 1678 and 254 had done, only using wheels on one side of their shooters.
The moment we removed the top right corner’s set of wheels, we saw a great improvement in the flight of the note. It made flat shots instead of flopping shots, but it occasionally left the note tilted to the side, since the right edge of the note was not supported at all. To fix this we added a thin aluminum tube 2.5” in diameter to our lower shooter axle to stabilize shots. With a similar one on top, this would be equivalent to a zero-compression roller pair, but we did not need one on top to keep the note flat. After these changes, we are shooting much better. We can make accurate and flat shots from 15 feet away from the speaker now. This also allows us to speed up our autonomous pathing and reliability as well, which is a big win.
Amp Scoring
Another big issue we found at Ventura was our amp consistency. When we first tried our amp shot at our workshop, we were getting about 60% accuracy. But as always, when we tried amping during actual matches, our scoring accuracy was around 20%. This was a major problem. If we couldn’t score in the amp, we simply wouldn’t be competitive enough to win. This showed in finals match 1, where we (alliance 5) scored more notes than alliance 1, but they had a significant score lead. This was partially from autonomous, but also because they were taking full advantage of the amp.
This got the CAD team thinking of fast, light solutions to implement before the San Diego regional. We took inspiration from team 2910’s amp bar and sought out ways to fit it onto our current robot. In the design we came up with, the bar flips up so that when we shoot into the amp, the note will go through the gap between the bar and the amp, and if it tries to fall out, it will hit the bar and score into the amp. We landed on a design which uses a single NEO to flip up a thin polycarbonate panel with a ⅜” round shaft going across acting as the bar. This design uses holes that were currently on the climber box tubes, which makes the assembly process much easier.
There was one problem in the V1 of this design, where we were not fitting inside our frame, or reaching the right spot for our amp shots. This problem had to do with the width of the polycarb, and was easily fixed. We also needed to move the mechanism up by an inch, since it blocked the driver camera and was not quite long enough. Now the bar stows almost underneath the shooter, fits perfectly within our frame perimeter, and also reaches the sweet spot for amp shots. The nice thing about this amp add-on is that it was designed, manufactured and assembled within 18 hours. This only took 2 versions, and we may still iterate it to further improve its performance. It has significantly improved our amp shots from the previous 10% accuracy to now a 95% accurate shot.
Cameras
At Ventura, we had plenty of trouble with our five cameras, due in part to the network issues, but also due to the field being knocked out of spec. We didn’t see the speaker panel warping issue that others had noted, but our autos did suffer from jumpy pose estimation as the robot picked up various tags on its way to the midline. For the later quals and playoff rounds, we were running with only the 2MP camera centered above the shooter. Even with just this camera and odometry, our autos were consistently up to 6 inches too close to the alliance wall on blue alliance specifically, for both the midline and 4-note auto. Unfortunately, we did not realize until finals that the subwoofer and speaker had been pushed back by about that much due to repeated robot impacts. Since we zeroed odometry against the subwoofer, and the one remaining camera only really saw the speaker tags during auto, this explained how the pose estimation looked right against the subwoofer, but 6 inches off at the midline.
Due to the networking issues and the trouble we had coordinating five cameras, we permanently removed the four we had disabled and took out their Orange Pis. This cleaned up the wiring in the upper electronics panel significantly, since the Ethernet, power wires and four USB camera cables no longer needed to be there. We also ignored every tag but the two speaker tags for purposes of multi-tag estimates. Since the field didn’t hold its shape, we didn’t want to receive invalid measurements combining tags from two field elements. Testing our autos again, we found that odometry alone was good enough for the portion of the path that was out of sightline of the speaker. Our wide intake helps with error tolerance at the midline.
LEDs + Driver Feedback
Another major improvement was to add a strip of addressable LEDs above the shooter. These communicate the status of the robot to the driver, so he can keep his eyes on the field. Currently we have a few patterns being used:
-
During normal disable, the bar is green.
-
During code startup, the bar is red, and remains red for a few seconds after the driver station light goes green, since we need to wait for all encoders to reset and resume reporting.
-
While the intake pivot coast-mode button is pressed, the bar is blue.
-
When either climber is raised enough that it would hit the stage, the bar goes rainbow. This is both an endgame “party mode” and an indication to the operator if they inadvertently raise the climbers during a match.
-
When the intake detects a note, the bar flashes white three times, and the driver controller rumbles. This is tied into our general intake routine, so it happens in auto as well.
-
Finally, on top of whatever active state is highest-priority, we overlay orange sections to show the position of detected notes:
The code we use to prioritize which state to show on the light bars is here
Autonomous
Apart from the camera and comms issues that affected our autonomous reliability at Ventura, we also needed to improve our overall autonomous capability to be competitive at SDR. Using Choreo for autonomous paths allows us to extend our routines easily, using the generalized “drive-intake-feed” command from before Ventura. However, our main constraint in autonomous mode is the time limit, so we want to minimize the time spent not moving.
To accomplish this, we simply removed all the pauses we could in the autonomous routines. We still come to a stop before shooting, but begin moving again before the note has fully left the shooter. At the first split-second of the path, the robot is slow enough that the shot is still consistent. Here is the improved four-note auto, with enough time overhead to do one or even two midline notes.
We also took advantage of our newly stabilized shooter to rethink our 3-piece midline auto. By going through the stage area, we can reach a usable shooting position more quickly than driving back around the stage. This gives us the chance to go for a third midline note. Here’s a before and after of the midline auto.
Unfortunately this new routine is 14.4 seconds of driving, so the removal of all pauses is imperative. We should at least have enough time to pick up the third center note, but it remains to be seen if we can score it during autonomous. Below is a clip for midline 4 note auto, further improvements have been made since this was filmed.
Autonomous Rotation Override
One side-effect of the shooter spin is that the shot goes approximately 6 degrees to the right, from the shooter’s perspective. This means that mirroring our autos across the midline to the red alliance doesn’t work quite right, since that offset is not also mirrored. Instead of making slightly different paths for red and blue, we tell Choreo to drive as if the shot was straight, and then use PathPlanner’s rotation override to aim at the speaker, compensating for the 6 degrees right. We use this override for all 4 close notes (as shown in the video above), and for the last ~0.75 seconds of each midline cycle. Though changing the rotation target at runtime can make a Choreo path infeasible (i.e. outside the robot’s limits), we have enough margin to handle this 6 degree difference in desired heading.
Off to San Diego…
11 Likes
San Diego Recap
Spoilers…we did not in fact fix our comms issues.
San Diego Regional was a frustrating experience for both our pit crew and our supporters in the stands. Almost every match, we would have at least one, and often several, disconnections from the field. These events interfered with autos and teleop cycles, and once happened while we were climbed, causing the robot to fall to the ground before the end of the match. Just like at Ventura, every match we would go back to the pit, check the DS logs and confirm it was the same issue, and try swapping another component.
Several times, we found something that seemed to be the problem, and we would work flawlessly for a match, and then be back to the regular disconnects for the next match. Throughout the event, as we swapped parts, the disconnects lasted longer or shorter, and seemed to be triggered by different actions. In total, between load in and load out, we tried:
2 network switches (swapping brainbox to a Netgear switch)
3 radios (all with and without the electrical isolation fix)
3 ways to power the radio (barrel jack, PoE, and RPM)
2 Ethernet cables down to the Rio (one unceremoniously running outside the front electronics panel)
2 roboRios (the one we have been using has a slightly mis-soldered pin on the Ethernet jack, but swapping this seemed to make no change)
2 SD cards in the Orange Pi (this was unrelated, one popped out and was never seen again)
This is on top of the pre-SDR changes, which included removing two of the Orange Pis, replacing every Ethernet cable on the robot, and swapping from an RPM to a barrel jack solution.
Nothing seemed to change the issue conclusively.
Despite all our issues, we still scored strongly when the robot was connected, and we finished rank 10, as one of the more effective speaker cyclers. Speedy cycling means an extra 2 seconds being disabled every other shot doesn’t affect too much, compared to a slower cycler. However, it’s a recipe for trouble in the playoffs, especially San Diego playoffs. Surprisingly, our friends 4738 Patribots took the risk on picking us and 2839 Daedalus, and we made it to match 13 before our communications issues showed up worse than ever before, and we lost the match, breaking our 2-regional finalist streak.
We did end up winning the Innovation in Control award for our LED bar that showed the notes being detected by the driver camera. Some aspects of that system were definitely chosen to make it more appealing for judges, such as letting it work while disabled (and thus during the comms dropouts), and darkening the rest of the bar so that we could still use orange for the detections. So when we were announced for IiC, it was somewhat relieving that at least something on the robot worked like it was supposed to.
Before we go on, I’d like to thank the CSAs and other mentors who looked through our logs and electronics, and otherwise offered more ideas to throw at the wall. A few of these CSAs paid us frequent visits at both Ventura and San Diego, and left just as baffled as we were. Though none of the ideas really helped, we appreciate the continued attempts to solve our issues.
“It might not be the problem, but it’s definitely a problem”
This phrase comes up often in our troubleshooting sessions, and it’s always a little disappointing when the issue identified is not in fact the problem. With that in mind, we don’t want to call anything fixed until we see the robot in action at Orange County this week. However, during load-out and workshops after the event, we identified a few more problems that may or may not be related. Since the disconnect issue had been reproduced on multiple separate control systems (by way of all the swaps being done), we finally focused on the driver station.
- Our on-field DS logs and by-ethernet DS logs show zero packet loss. Not even a few dropped packets here and there, but absolutely nothing on the Packet Loss graph. But packet loss/delay is definitely a problem. One of the weird parts about our issue is that the RSL goes solid, the motors get disabled, and the stack light above the DS starts blinking, but the code continues as if it’s enabled for up to 5 seconds after the solid RSL. This is most evident when we disconnect during auto, as the routine does not get canceled if the dropouts are short enough. In fact, on a few occasions, it recovered enough to pick up the last note.
- Further investigating this issue by syncing our DS logs and WPILogs in Advantagescope, we confirmed that the DS enable status and robot code enable status were mismatched, as it seemed from the outside. Thanks to Will Toth’s knowledge of the FMS network traffic flow, we learned that this pointed to network packets going missing somewhere between the driver station and the roboRio. Apparently, the motor safety layer has a shorter timeout for missing packets than the DriverStation class which triggers the code state transitions between enabled and disabled. This may be a new change as part of the tighter timings on DS packets introduced in 2024.
So the DS does not see any trouble whatsoever with packet loss, but the packets are not always making it to the roboRio in real-time, if at all. Was something on the DS intercepting network traffic? Something like… - The Autodesk Updater
This is our biggest candidate right now for the main issue, and it’s something we should have checked long ago. I know Autodesk Updater has been known for years to cause packet loss with the driver station, and we did use Inventor on that laptop frequently to set up CNC jobs. Yet somehow, I didn’t connect the dots until I clicked on the Updater system tray icon while trying to check network selection. Still not sure what lessons we need to take from this, besides “the Driver Station best practices are there for a reason, so don’t install ANYTHING unnecessary on the DS laptop”. We have now removed all Autodesk products, and will be removing REV Hardware Client, the Computerized Battery Analyzer tool as well. - Another potential cause of issues is that we’ve been running with the DS not connected to power when on-field, due to issues with its touchpad on “dirty ground” AC outlets in the pits and on field. I’m not the electrician here, so I’m probably misrepresenting what I read on the tech forums, but given that it happens only when connected to power, and only when far from a wall outlet, this seems like the likely cause of the touchpad issues.
- Running a DS on battery is not advised in WPILib’s DS Best Practices, and in poking through Device Manager, we found out why. Though the USB ports were not set to power-saving mode, there was a checkmark on “Intel Ethernet Connection: Allow this PC to turn off this device to save power”. Again, certainly a potential problem. We can’t say for sure, but with that setting on, the state of the PC’s battery may have had varying effects on the Ethernet port, perhaps causing some of the variability we saw throughout the day. While in Device Manager, we installed a driver update for the touchpad, but we may end up needing to just deal with the touchpad issues on-field.
In summary, the changes that we’ve made are
a) remove all unnecessary programs, especially Autodesk
b) run the DS plugged in from here on out, hopefully with some other fix to the touchpad issues,
c) static-IP our driver station to 10.69.95.5 to help with network connection times and reconnection in case of radio reboot.
Again, we don’t want to say anything’s fixed, since we haven’t run the robot at all since the last match of SDR. But at least now we’re finding problems that have been known to cause issues in the past, instead of just getting our hopes up after noticing the one different pin on the roboRio board. If these don’t fix the issue, OCR will look about the same as SDR, but if we’ve actually solved it this time, we’ll be back to consistent full functionality just in time for our last and potentially most likely shot at Worlds. We have some ambitious changes for OCR, but those will have to wait for another post.
15 Likes