FRC 95 The Grasshoppers 2023 Build Thread

FIRST Open Alliance
38

Let’s talk about when things go wrong. Sideways. Pear-shaped.

This post is partly spleen-venting, partly commiserating, and partly encouragement to work through obstacles you may encounter.

Things will go wrong. In fact, I’d wager that if nothing went wrong in our build/competition season then we weren’t pushing ourselves enough. Though it does seem like this year has more SNAFUs than average…

We preordered the MAXSwerve from REV. Due to a number of circumstances largely or entirely out of their control the kit delivery was ~3 weeks late. No sense it getting upset at REV about it though. I know that they did everything in their power to make up for the delivery delay, including working over the weekend. We got our kits yesterday, phew, and started assembly.

What can we do when a critical part is delayed? Plan, model, read other OA threads, read the MAXSwerve assembly instructions. Plenty of things to be productive before we had the kits.

We ordered a 3D printer farm before the holidays… but… supply chain, holidays, school purchasing systems, and timezone delays means we don’t have them yet. So I am printing stuff at home, and we are changing our design path to avoid quickly-printed parts.

I chose to have the KoP delivered to us this year instead of having someone drive ~3 hours round trip to a kickoff event to pick it up. I figured shipping was easier on our time and lessened our carbon footprint. I even opted us out of the big totes so shipping should be a breeze, right? Nope. $200 for shipping and 6 days later we finally got our game piece box…

This is by far the most frustrating snag so far this season. We lost ~6 days with game pieces and paid $200 when a flat-rate USPS box would have had it to us in one day from HQ. Thank goodness for the other OA teams and Ri3D teams who prototyped lots of intake and gripper prototypes. We studied, read, and watched everything we could to get a good idea of where we wanted to go when it finally arrived so we could hit the ground running.

Stay positive, find what things you can control and work on, keep energy productive and focused. May you find the luck we seem to have lost!

34 Likes
39

Ours shipped Thursday, we rec’d on Friday. $200 for late shipping and one small box full of stickers is not great.

4 Likes
40

We still haven’t received ours :cry:

3 Likes
41

Bruh…

If you want anything tested please post here or in another OA team thread. We will do what we can to accommodate it.

9 Likes
42

Same here…

1 Like
43

Lots of things going on. I’m going to post a general overview and tag my students to expand on their respective sections.

Our over-arching design goals are:
-Fast and chaotic (@Kevin_Leonard) e.g. short cycle time with a flexible cycle path
-High effort to minimize arm/effector/moving mass and keep CG low
-Modest flexibility with game piece collection
-Synergy but not dependence between subsystems e.g. arm and gripper can pickup from HP shelf and score, intake alone can ground-load and score in the hybrid nodes, and with the handoff we can ‘touch it, own it’, handoff while driving, then score anywhere
-Vision assist for scoring, code limits/safetys for driving, e.g. make the robot as easy to drive at the limit as we can
-Do a bunch of things we haven’t done before

This is unlikely to be the best recipe for many teams’ goals. We are making intentional design choices to result in a wild, interesting, and fun-to-drive robot. Not necessarily the most competitive robot (though I think if we get it sorted this design has a very high scoring ceiling).

One of @Wesley 's recent tasks has been to write to limit acceleration vs cg location (i.e. the scoring arm in our competition robot) to prevent tipping. The kids… uh… made a CIM lance and cobbed it onto our swerve chassis and… boy that’s a lot of chaotic energy.

Here is a video of some debugging driving. It is mostly working in this video, but not completely. Note the control stick is going full range of input but the robot’s acceleration is extremely limited.

Also, yes, our practice area gets used as storage in the offseason and we haven’t cleaned it out or replaced the carpet yet. It’s on the list.

Our mk1 CAD is mostly roughed in. We are planning on a multi-position linear intake (heavy) that hands-off to a 1DoF gripper on a 1DoF arm (light) riding on top a MAXSwerve chassis.

@JWC_95 is lead on the arm and superstructure. We’re going to use carbon fiber tubes for this framing, but with an aluminum scab plate construction because we don’t have access to high-end/reinforced 3D printing resources. A good bit of care has gone into these terminations and packaging the drive motors and v4b components.

@StephenWitwick is point on the gripper and a few other components including the swerve protector shields, which add a nice splash of color to the MAXSwerve modules.

The gripper, so far the only use of pneumatics on the robot (which we discussed and agreed on), is <3lbs. Keeping this mass as low as possible will maximize robot driving speed and arm speed and ultimately lower cycle times.

End effector mass is a great example of mass-compounding, which I’ll cover in a follow-up post.

I’m taking lead on the intake assembly, which is intended to be heavy to help drive the CG down. It is going to use a linear drive, looking like a round gear rack, to move in/out/. The hotdog style rollers will be driven independently to enable cube intake against the bumper (rolling both inwards) and pinching cone flanges (rolling them against each other).

Stored:

image
image754×349 40.2 KB

Tipped cone flange pickup (cone point on the ground, facing away from robot):

image
image726×353 43.8 KB

Fully deployed to intake cube against bumper:

Naturally there are a lot of details to sort out in CAD, but most of the big things are there.

11 Likes
44

Acceleration limiting is split into two parts: calculating the maximum acceleration, then actually implementing the limit. James beat me to it on the physics for this one, but the maximum acceleration without tipping works out to gravity * (horizontal distance from CG to edge of wheelbase) / (vertical distance from CG to floor):

image (1)
image (1)1183×790 50.8 KB

This is useful, but in order to actually implement it on the robot, we need to know where the robot CG is and how far it is from the particular edge of the robot that we’re driving towards (or maybe away from? still not sure about that).
Finding the robot CG is simple, because it is just the standard two-mass CG formula, using the chassis cg position and the manipulator cg position. The manipulator cg position will eventually be read from NetworkTables because it will change as the arm moves around.
Finding the horizontal distance is more interesting. First, the actual robot cg is projected onto the line that runs through the geometric center of the chassis, at the desired angle of travel (the “direction line”). One of the four lines that make up the edges of the robot wheelbase is projected onto the direction line— this is really just the point where the direction line intersects the edge of the wheelbase. From there, finding the distance between two points is simple, and the max acceleration can be calculated.
This calculator has most of it, but be warned that it’s not entirely polished and may behave unexpectedly. Also, some of the parameters are in the “calculations” section:

Limiting acceleration:
This part has, surprisingly, caused more trouble than the acceleration calculation. Because the robot is controlled with velocity commands (field relative x and y, in meters per second), we need to turn an acceleration limit into a velocity limit. Seems simple, right? Just use Vf = Vi + at, and you have a maximum allowed velocity. Well, sort of. Vi is easy enough to get, because the WPI kinematics classes exist. The velocities reported by kinematics do need to be converted to field-relative, but this is pretty easy.
a needs to be a vector, because Vi is a vector. Given a direction, the magnitude of a is calculable— that’s what the calcMaxAccel() function described above does.
However, its direction is the same as the change in velocity being requested— in order to reach a new velocity, we must accelerate in the direction of delta V, the difference between current and commanded velocity. Once again, WPI makes this easy, because Translation2d handles all the vector math.
Unfortunately, we still need t. At first, I set t to 0.02 seconds, because the robot loop is 20ms. This resulted in the sluggish acceleration seen in the testing video, which is definitely not the 13m/s/s reported by the acceleration function. This was the cause of much head-scratching, until I eventually remembered hearing about the velocity measurement of NEO/SparkMAX/brushless motors in general being slow. After looking it up, finding a 112ms latency, and adding that to the 20ms loop time, everything seems to be working properly.

All the code for this is here:

Other stuff:
We are planning on going crazy with fancy sensors/cameras this year— we’re looking at 4 limelights and a jetson. This means an 8 port switch on the robot, which means a nice power supply for it and possibly the jetson too. And the limelights when w don’t believe that they can handle unregulated power. James told me to ask @marshall about voltage regulators or buck/boost converters.
As for what these things will do, the jetson will hopefully be running LiDAR localization, at least one camera will be pointed at the intake area for automated gamepiece acquisition, and the rest will be used for AprilTag localization. Maybe one will end up on the arm, and it can do terminal guidance with the retro tape for cone scoring.

10 Likes
45

Ask away!

1 Like
46

That’s about all he said. I think he was looking for recommendations for something to power the switch and maybe jetson.

1 Like
47

My general practice is to start by saying “how low do I need to run this thing at?” and then because, it’s FRC, the answer is typically “as low as I can manage” so I settle on like 3-4V as my lower bound.

From there, I take a trip over to pololu.com and look at their selection of regulators and then make a decision on if I need boost, buck, or a combination of the two depending on the voltage I am running at.

Then I start looking at the maximum power outputs and various curves and other specs. Most of the time, that gets me to what I want. Sometimes I have to look elsewhere and some other times, I get a new mentor who has an background in EE and embedded work and wants to use Altium with some students to design a highly custom board that I’m eager to see in action.

3 Likes
48

Gripper materials!

We finally had a chance to test different gripper materials. We have a pretty big collection from over the years, so the first thing the students did was a hand-check to pare down to a few candidate materials for more detailed testing. They picked wedgetop, roughtop, and a firm drawer liner material for additional testing. Here are the results:

This friction test was an inclined plane method, carefully increasing the plane angle until the object slipped. Each measurement was repeated 3-4 times and the cone was tested in two orientations to help understand the effect of edges of the cone digging into the material.

Wedgetop (1) had good grip, but is pretty heavy, so meh
Roughtop (2) had comparable cube grip, but less cone grip, boo
Drawer liner (3) had good friction on both the cone and the cube and is the lightest, yay

So we will proceed with using drawer liner material for our rollers and end effector.

4 Likes
49

Got a link to your drawer liner?

2 Likes
50

Is the 4 limelight’s for 1 limelight on each side of the robot or some other arrangement you haven’t figured out yet?

1 Like
51

Unfortunately not. We got it at HD a few years ago and it doesn’t look as if that precise product is made anymore. I suspect one could spend a little quality time in-store and find the best option with a simple hand-check though.

52

Blue plate is polycarbonate, yeah? Linear mechanisms with precision guides give me the heebie jeebies, you just know a rail will get bent.

53

Yes, blue arms will be PC or nylon. The orange scab plate will be aluminum to support/capture the bearings.

Pretty sure if we bend 3/4in steel rails we will be in serious trouble!

To mitigate the binding risks of linear rails on a robot the two rails are mounted with relatively flexible tabs. Thus if the frame gets tweaked the rails will not be forced to bend too. The mounting tab includes a slot for finer manual alignment of parallelism before tightening the rails down. The bearing blocks have plastic housings and are mounted to sheet metal, so all of that can flex a little bit if things get weird.

I am a little worried about the spur gear deflecting out of the rack, but we can stiffen up that area if needed. The whole idea with the gear drive is to use as little reduction as we can stand and a low current limit so it will back-drive if it gets hit.

1 Like
54

Not really sure yet. Had some ideas about binocular vision, and one might end up on the arm, and another might be looking at the floor in front of the intake.

1 Like
55

Is there a reason intake geometry wise thay your intake has that subtle curve to it, or is that just aesthetic?

56

Yes and yes. The curve is a subtle transition from the required height and location of the pasta pincher rollers to the required height and location of the intake carriage to package with the arm.

And if you’re going to design something, it’s nice to have it look good.

2 Likes
57

The bougie hoppers.

2 Likes