FRC Team 3324 (Unofficial) Build Thread

[inam]

So I was inspired by the Open Alliance thread and by extension team 95’s build thread. I highly recommend going through both (as well as the 4481 thread, I sadly have not looked at any other threads/blogs in great detail).

Github
Everything stated is from my point of view, I’m a programming member so I might get the details a bit wrong on the build, sorry in advance.

Either way, since this is coming in a bit late I’m going to go through some of the decisions we made and how we got there. So, I’m going to miss some stuff but I’ll try to rush through it.

Kickoff:
We spent most of kickoff just reading the manual. We split into groups, presented what we though was important, etc. Not many decisions we discussed/made, which is pretty standard for us.

Sunday (Jan 7th):
Sunday we tried to make as many drivetrain decisions as possible, with a couple key things changed since last year:

1. We decided to go with the Vexpro 3-cim ballshifters instead of the 2-cim ballshifters. We will run these with 3-neos for a 6-neo drivetrain. We really don’t think we’re going to have any other large current costs since most other mechanisms (probably) won’t run when drivetrain is running (ie. you wouldn’t shoot and drive at the same time). We think the extra pushing power/acceleration is nice, but we won’t know if it was worth giving up what we’re comfortable with until it’s built.

2. For wheels we decided to go with the WCP 6-inch pneumatic wheels. After some initial testing, we decided that we weren’t completely comfortable with how traction/omnis/blue nitrile wheels went over the 1-inch metal bumps.

3. We also geared around 2 ft/s faster in high gear than we were last year since we’re going across the field more. We hope that the pneumatic wheels let us stay pretty quick even while going over the bumps.

End result:

Monday
So for Monday it was really all about getting our priority list locked in.

I personally made a spreadsheet with all the actions I thought were important and some point scaling based off how hard/repeatable I thought actions were. Another student made a quick slideshow with possible strategies. These helped us do a bit of analysis before our official practice times.

On Monday we decided that we should go with a High Shooter + Climb, though I am a bit worried about going for climbing and biting off more than we can chew. That being said, both more experiences members and younger members agreed we should do it so it seems to be a solid strategy decision. Our priority list ended up looking something like:

1. Ground intake
2. Outer high goal shooting
3. Climb
4. Trench

As of now Trench is kind of in a weird place. We said we’d decide whether we want to keep it soon, I expect the latest date to be January 18th, but we’re looking at doing it this coming Saturday/Monday if I recall correctly.

Tuesday
With our priority list locked in we could now decide goals for mechanisms. I also got the code working with the 2020 Commands and 4 Neos, I’m very happy with the new Command-based stuff and am excited to keep working on it (writing this now I realize I forgot to push the code, that should get to the Github around noon tomorrow).

We had mechanism leads/other managers meet up to quickly draft up main goals for each mechanism while the rest of the team brainstormed mechanism ideas.
We ended up with:
Requirements
Intake

1. Touch it, own it
2. No jams
3. Should be able to intake 5 balls in a line in ~3 seconds.
4. Programming should be able to somehow count how many balls have went in (currently planning on measuring current).

Shooter

1. Aimed loosely for inner port.
2. 99% accurate at full RPM while shooting from the initiation line (Auto)
3. 90% general accuracy
4. 4 second full unload (not Auto)
5. 45-degree effective range.

Storage

1.Store exactly 5 balls, ideally aligned to shoot.
2. Manual ball removal

Climb

1. 15-second climb from when you enter the rendezvous zone.

Auto

1. Three balls, 99% accurate outer high goal, 5 seconds
2. Three starting positions
3. Cross line

We also went through and did a quick 30-second robot sketch of what we thought we generally wanted our robot to look like which came out to this:

.

That’s about where we are at right now. I’ll try to update the thread daily albeit with much shorter posts, with a longer post later on in the week. First time posting really anything so please give me any feedback you have, and I hope someone finds this useful.

[JamesCH95]

Awesome! Good luck and thank you for having an open build.

[inam]

Boop
Today we had our annual strategy meeting. It went pretty decently, had a lot of Columbus teams over (thanks for coming if you’re reading this!). We also had tOSU present their ri3d robot which garnered some pretty good discussion. Before that I was a bit disappointed by the amount of discussion happening, but it seemed to pick up well at the end.

We did some code stuff and I was able to push the code to Github. We started writing stuff with RamseteCommand but it sadly did not work, I’ll check it tomorrow but that drivetrain is probably going to be taken apart for a bit. I’m planning on testing if I can count how many balls go into a mechanism using current drawn from a flywheel (not a very…conclusive test).

I’m not really sure how mechanisms are going since I didn’t really interact with them but drivetrain stuff was seemingly ordered so we should have it built soon, though we might be a bit behind schedule, I’m not sure.
Beep

[inam]

So not as much happened today for me. I mostly walked around setting up some stuff and trying to find jobs for my minions programmers, we got a test electrical board setup to see if we can detect whenever our intake takes in a ball. Me and another student worked a bit on getting torque requirements for a 2 pound intake if we wanna accelerate up to 7000 RPM in one second. We didn’t account for the fact that as RPM increases the torque of the motor decreases but I think it’s a close enough approximation for now (as we don’t really know the actual weight of the flywheel or anything). Here’s a picture of the work:

I highly recommend that any teams designing with 775s make sure to design to stall at 3.5-4V with a decent factor of safety, otherwise you risk burning out your motor, make sure to look at the Vex data:

Not much information has been put out on when the Neo 550s burn out so I might stall one at 6V (which is what we designed for) and see if it survives for a minute or so. One of our programming students has also made decent progress in getting vision to work. We don’t have practice tomorrow so depending on how much I do I might not send in any updates.

Also for any other teams doing shifting gearboxes I recommend looking at this post from team 95’s build thread. I’m pretty sure there is a way to get the ideal shifting point for your DT empirically via power curves and some data plotting but this seems like the way I’m going to do it since I’m pretty lazy. I ran it through with the Neo RPM to get: 5667/(19.61 + 9.07), which gives me 197.594142259 RPM which is…approximately 5.166666666675 feet per second. I’m not completely sure if it holds for multiple motors but I think it would since the terms fall out anyway (as long as you have the same number of motors on each side of course).

[AriMB]

@inam

I’m not completely sure if it holds for multiple motors but I think it would since the terms fall out anyway (as long as you have the same number of motors on each side of course).

That’s right, the term for ‘number of motors’ should cancel out same as the stall torque. So would a term for efficiency if you wanted to add that. The only thing I can think of that wouldn’t cancel out would be if you were sprinting at less than full voltage, then you would have to multiply both the stall torque and free speed by the voltage ratio (V/12). So that would mean multiplying the final shift point equation by the voltage ratio as well.

[inam]

Yeah, that all makes sense to me. We might throttle to 11V just to drop a bit of the non-linearity on the upper edges of the motor curves and be safe. Are you saying we would do:

\frac{\frac{11}{12} * \omega_f}{G_1 + G_2}

Because that’s my what my intuition tells me (just pretend like it’s at freespeed at 11V).

[inam]

Today we made some significant progress.

Drivetrain seems to be a bit behind but it’s not significant enough for me to really be worried. As long as it’s reliable and works we should be fine even if it’s a week behind schedule (which it definitely is not).

Intake/shooter/climber groups have started thinking about prototypes. Intake specifically has been getting farther along. Looking at other teams I guess we start prototyping a bit late, I don’t really know why but I’m not in a rush anyway and I’m sure mechanical got it figured out (they know what they’re doing).

Electrical finished up the electrical board for the drivetrain and did some miscellaneous stuff, there was some confusion where we thought we lost some Neo 550s because they don’t have any sort of special packaging (just a small white box) - on that note if anyone has information about when they burn out that they’re willing to share that’d be great.

Other than that programming did some miscellaneous work as well and really ramped up on vision (if anyone is interested I did provide reasoning as to why we avoided a Limelight or Chameleon vision at the end of the post). We first got some simple tracking working with retroreflective tape (this is our first time doing vision so it’s all new to us) as can be seen here:

That’s using the OpenCV sliders and GUI tools, which seem really nice, for some reason I feel like I see them out in the wild pretty infrequently, we found them pretty ideal. We then took that on the field and did some testing, I don’t have any pictures of our initial testing (we tracked the target fine) but I do have this image if anyone is interested in how the target looks from the trench:

This is with a lifecam HD-3000 and a decent LED ring but definitely not an exceptionally bright one. We’ll probably get brighter ones toward the end of build season.

We decided that was all well and good so implemented a rough angle-detector algorithm in:

We aren’t planning on doing anything beyond pressing a button and aligning horizontally so this is probably as far as we really need to go. We didn’t do any fancy focal length stuff, just used the FOV since we think it’ll be good enough.

What we have so far (github).

Why Didn’t We Use Chameleon/Limelight/Whatever
I’ll start off with the easy answer: we didn’t use limelight because it simultaneously diminishes learning value, and costs (imo) way too much for what it is. I have full respect teams who use them and have success with them, but I personally see no reason to use one over a Pi 4 + Chameleon Vision. The only reason we didn’t go with Chameleon Vision is because I was more familiar with opencv and python (see this repo that I made after powerup to detect a power cube). There was also some more specialized stuff I want to do eventually (like sending data over zeromq) that I’m just not sure is possible with Chameleon Vision (though I haven’t looked into it so it’s possibly that it is and I’m just ignorant).

[inam]

So…I forgot to update this on Monday so I’ll cover both yesterday and today right now.

Monday
Programming worked a bit more on vision and wrote code for the shooter prototype. We have a rough idea of what we wanna do when the DT is built but sadly it’s still a bit behind schedule. Intake/shooter groups are working on prototyping and climber is getting there.

Tuesday
Shooter testing code is finished and shooter prototype is finished, but we have no great way to mount it so we’ll test tomorrow. DT is still not done but hopefully will finish first thing Wednesday morning, fingers crossed.

[inam]

Today we mostly worked on getting the drivetrain up and running, it’s finally in my dirty little programming hands so I’m working through the kinks with the Spark Maxes and everything, but it’s going decently. We did also do some shooter testing that ended up going pretty well, we got into the high goal at around 60% rpm, but we only had one motor and didn’t test acceleration time or anything.

[inam]

So we had a pretty big day today, drivetrain got working and shooter got really going testing wise. We’re working on autoshifting on programming and shooter group has split into testing and ball management. I haven’t really worked with intake but they have printed some 2in mecanums and cut up some stealth wheels and are working with that (I believe). Climber had a small design review but I wasn’t there and am not sure on status. Videos: https://photos.app.goo.gl/KVsqHFunudyBVVpV9
We used this calculator to get the following numbers:

That is what we tested with and got those 3-point shots with in the videos, we ran at 5250 RPM but only with a feedforward not accounting for steady-state error so I knocked it down to 5050 in the calculator. I’ll get more detailed information on Saturday.

[inam]

Saturday

So we did a lot of shooter testing as well as got DriveTrain autoshifting working. I still think that we might have some gearing/encoder issues in our DT but we did characterize and stuff. Here are our gains (with an incorrect wheel diameter in analysis and potentially incorrect encoder conversion) for high gear and low gear, respectively.

Monday
So…we discovered that the shooter sprockets were put on flipped on one side which essentially invalidated a lot of our testing. It was a setback but I think we made good progress in retesting everything to where we wanted it (eventually getting it so we could shoot into the inner port even while offset). We also finalized drivetrain decisions for our final DT, Videos of everything we tested can be seen here. We also had a lot of back-to-back meetings about what we were going to do in terms of integration and there are still a lot of unknowns but I think we feel ok about everything.