WildStang Robotics Program: Team 111 and 112 Build Blog - 2023

Probably just some UHMW glide pads to take the impacts. Still not sure if we’re fully committed to this however.

Electronics packaging is uh… tight.


For what it’s worth, if you’re using pose estimation with AprilTags, you don’t need to see the tags themselves when scoring, just periodically during the match. If you are planning to turn to the pegs like people would do with the tape but with an offset on the AprilTags, then you would want to see them.


Other huge benefit here is it allows a partner to pass behind us between the hybrid nodes and the charge station.


Wonderful writeups WildStang!


Hey Everyone! With week 1 in the rearview mirror, I’ll share a bit about what the software team has been up to since Kickoff!

Organization during the year:

We’ve got a lot to manage with two separate teams, two separate robots, and a lot of code to write and review. So, one of the most important things is to make sure everyone is on the same page and up to speed with what’s going on. There’s a lot of ways to do this, but we rely on our full team meetings on Monday to talk to everyone at once, along with some visual aids for current projects and “what to do’s.”

We also keep an Excel sheet with a list of current projects, completed projects, and what all the branches of our repo’s are for. It’s a fairly nice and accessible way to keep track of what’s going on for both the mentors and the students. There’s also a “current state” for each project, which can indicate whether it’s started, working, needing review, or waiting on other subteams. This makes it easier for the mentors to see what needs their review, and if anything needs pushing forwards or has hit a wall.

Rev Swerve!

Hardware put together a test chassis with the rev swerve modules, so we got a chance to test our swerve code and had the robot driving! You can find that swerve code soon on our framework repo, but here’s some cool controls aspects of it that don’t get talked about as much as they should.

Scaled deadbands: Important for driving the robot slowly while also properly deadbanding controllers (where the joystick might not rest exactly on 0 when not in use). With normal deadbands, you can’t actually drive the robot slower than the deadband value, which can lead to slightly jittery control while going slowly. Scaling it properly from 0 to 100 after the deadband helps keep the robot controllable at the slowest speeds.

if (Math.abs(input) < Math.abs(deadband)) return 0.0;
return deadband*Math.signum(input) + ((input - deadband) / (1.0 - deadband));

PID lock: rather than having the driver manually rotate the robot to certain headings, we can have the code “control” the rotation joystick to move the robot to the correct headings. We typically use these for North/East/South/West heading locks, but you can also do it for any other directions you might want to face.

/**automatically creates a rotational joystick value to rotate the robot towards a specific target
* @param i_target target direction for the robot to face, field centric, bearing degrees
* @param i_gyro the gyro value, field centric, in bearing degrees
* @return double that indicates what the rotational joystick value should be
public double getRotControl(double i_target, double i_gyro) {
    rotDelta = i_target - i_gyro;
    if (rotDelta > 180) {
        rotPID = (rotDelta - 360) / 180;
    else if (Math.abs(rotDelta) <= 180.0) {
        rotPID = rotDelta / 180.0;
    else {
        rotPID = (rotDelta + 360) / 180;
    return rotPID;

Thrust: a simpler one, it can be difficult to control a robot going full speed on the field. An easy way to make it a bit simpler is to only give the driver’s joystick some % of the robot’s full speed, and “unlock” the rest of the speed with a trigger. It gives the driver a nice middle ground of “fast but not too fast” for taking corners or accelerating without wheelslip.

thrustValue = 1 - DriveConstants.DRIVE_THRUST + DriveConstants.DRIVE_THRUST * Math.abs(rightTrigger.getValue());
xSpeed *= thrustValue;
ySpeed *= thrustValue;
rotSpeed *= thrustValue;

April Tags

We also spent some time experimenting with April tags using our Limelight 2+’s. It seemed pretty plug and play from our quick experimentation (though be sure to use the latest firmware for the limelights). We were really impressed by the lack of calibration needed, and how messing with the lighting didn’t really affect the detection at all. That’s going to be a nice change from worrying about LED calibration in previous years.

There’s definitely some tradeoffs to be made between distance of detection, frame rate, and relative confidence that we can detect at that distance. It seems we’ll likely be running 320x240 or 640x480 depending on how far we’ll need to see. (320x240 seems to run out to about 12 ft with good framerate, 640x480 gets to around 18 ft).



We have a robot!

Today was 111’s robot concept decision meeting.

We have been working two parallel robot designs to assess feasibility, but today we picked the one we will field at Midwest. This work can include everything from 3D space claims in CAD to fully complete robot-ready prototypes.

The two designs are known internally as “Say Yes to Cutouts” and “Say No to Cutouts”.

“Say Yes to Cutouts”
This robot for centered around our frame alignment cutouts outlined above.


Major Pros:

  • Mechanical alignment to goal may make this robot easier to drive.
  • Lift movement only required for floor pickup
  • Cutouts allow partners to pass behind us between goal and charge station.

Major Cons:

  • Frame design restricts electrical space
  • End effector difficult to iterate upon
  • Major packaging constraints limit design flexibiltiy


Frame cutout test chassis w/ Max Swerve.

Short version of the arm design concept to both learn the construction techniques as well as assess design durability. Things learned with this prototype is beneficial to both robot architectures.

“Say No to Cutouts”

This is what we’re calling the ‘normal’ robot. Angled lift with a reach arm that can go infront of or behind the robot. Does have one risky design feature with the open ended lift extension stage, but we think this is a manageable challenge.

Major Pros:

  • Frame design maximizes electrical space while minimizing CoG hit.
  • More flexible with end effector designs to allow iteration over the season.
  • Can incorporate familiar, proven design elements to achieve all reach goals.

Major Cons:

  • Software or less effective mechanical alignment system required.
  • Potentially higher CoG due to two stage moving lift instead of single stage.
  • Robot sticks out further into scoring lane, limiting ability of partners to pass behind us.

The team had an all hands meeting to discuss and evaluate these two concepts. We used weighted decision matrix to make our final robot decision.

We are saying ‘NO’ to cutouts. In the words of the 111 driver:


Also…the score came out to 42…so hopefully the guide is correct!
Looking forward to building this robot over the next couple of weeks!


Have you done any testing of the drivability of the rev swerve modules on the charging station?

Not yet, but I don’t have any reason to believe there will be issues. Clearance angles are all there, drivetrain power is there. I’m wouldn’t be worried.

I’m trying to understand how the “at YES to cutouts” arm scoring geometry would have worked - do you have any pictures of that CAD you would be willing to share? The arm looks very neat.


The concept was a 42” arm on a vertical lift with a virtual four bar to keep the end effector parallel with the floor. The sketch posted above shows all of the different key positions for scoring and intaking. The bend in the arm was to allow picking up from the double substation with the bumper contacting the wall. This concept was enabled by the cutout, since it allowed us to get much closer to the nodes.

Dang I was Looking Forward to seeing the cutout design in action - such a creative idea! Hopefully someone else picks that one up.


It’s a super-fun idea, and you could do it on one side of a kitbot by moving the cross-bot supports over the frame (so you clear the 5"). I also hope to see this in action on some robot or another.

How are the carbon fiber tubes mounted to the 3D-printed parts (I don’t see any screws)? Epoxy?


@JamesCH95 has a great post derived from a discussion that came from that arm.


This is great! Thank you so much!

RIP say yes to Cutouts 2023-2023

Praying another team picks this idea up would be real neat to see.


Hi, I noticed you are running wheels with black neoprene tread on your REV MAXswerve modules, where did you get the wheels? are the wheels 3in metal wheels from Thrifty Bot?

1 Like

It looks like their running the stock rubber tread for the MAX Swerve (unless I missed a video with the tread).

1 Like

It may have been another team I saw using neoprene tread

I believe that 4481 was running it in the reveal video because as beta testers they got the beta version of an aluminum tread wheel that can handle tread, Rev has said it will be coming, but have not confirmed a date

1 Like