FRC971 Spartan Robotics 2016 Release Video

[AustinSchuh]

Originally Posted by thatprogrammer

I have heard a few whispers that you run custom sized shaft in order to help achieve such precision. Is this true?

Yes. Every hex shaft in the 3 gearboxes that matter is custom sized to be about 4 thou oversized. The gears are a light press fit on the shaft.

We also run the first reduction as a well tensioned chain run. The chain has negligible backlash when well tensioned. You do need to tension it enough such that it doesn't go slack under acceleration and deceleration, or you add nonlinearities back into the control loops again...

Apparently you can do similarly good things with a soda can as a shim, or some other thin metal. We haven't tried that ourselves.

[thatprogrammer]

Originally Posted by AustinSchuh

We have our own framework for designing robot code. Our code is broken up into somewhere around 10 processes, each responsible for one part of the robot. 1 process is Autonomous mode, 1 process is the joystick code, 1 process is the hardware interface, 1 process is the drivetrain, 1 process is the shooter, 1 process is the vision udp listener, 1 process is the superstructure code, etc. Each of those processes communicate with our own PubSub message passing code. That means, for example, that the drivetrain will listen for Goal and Position messages, and publish Output and Status messages. (look in //frc971/control_loops/drivetrain:drivetrain.q for the actual definitions). This lets us be resilient to crashes, and keeps the interfaces between modules very well defined. For example, with 0 changes outside the hardware interface layer, we switched from running all our code on a BBB in 2014 to it all running on the roboRIO. We also are able to generate simulated Position messages and listen for simulated Output messages in our unit tests so that we can exercise the code without risking the real robot.

I'm curious about how this is being done. What file or class is used to actually join everything together and work as the "main" class that feeds all the others to the roboRIO itself? How are the WPILIB classes incorporated into this? Thanks!

[kylestach1678]

Originally Posted by thatprogrammer

I'm curious about how this is being done. What file or class is used to actually join everything together and work as the "main" class that feeds all the others to the roboRIO itself? How are the WPILIB classes incorporated into this? Thanks!

I'm obviously not on 971, but from what I can tell, the file you are looking for is y2016/wpilib/wpilib_interface.cc. It contains a bunch of helper classes to handle reading from the necessary message queues and writing to the WPILib objects as well as the equivalent of the WPILib Robot class.

[kylestach1678]

Austin, are there any plans for getting the changes made in your bazel distribution from merged back upstream? The code builds correctly using the build of bazel from your custom package repos but fails when using bazel 0.2.3.

[AustinSchuh]

Originally Posted by kylestach1678

Austin, are there any plans for getting the changes made in your bazel distribution from merged back upstream? The code builds correctly using the build of bazel from your custom package repos but fails when using bazel 0.2.3.

We are continually ahead and behind... We upstream our changes as fast as we can, but each upgrade seems to find more issues. Can you email/PM me the failure to keep this thread cleaner?

0.2.3 changed how runfiles work, and we haven't upgraded and fixed the issues. You probably need to go back to 0.2.2, and we'll work on upgrading soon. What we really should do is provide a //tools/bazel which pulls down the blessed bazel version. I think I sent you guys a pull request with that script in it. I'll see if we can get that merged into our repo.

[kylestach1678]

Originally Posted by AustinSchuh

0.2.3 changed how runfiles work, and we haven't upgraded and fixed the issues. You probably need to go back to 0.2.2, and we'll work on upgrading soon. What we really should do is provide a //tools/bazel which pulls down the blessed bazel version. I think I sent you guys a pull request with that script in it. I'll see if we can get that merged into our repo.

My bad. You're right - downgrading to 0.2.2b fixed it. I suppose that's the downside to using a tool like bazel where breaking changes occur every few releases.

Now that I've gotten to take a better look at the code, I'm amazed (as usual) at the sheer amount of testing code present. 1335 lines of code in superstructure_lib_test.cc ! How are you able to get people to actually write automated test code? We've been trying to make unit testing a more important part of our development process, but this past year we weren't able to make that happen as much as we would have liked for two main reasons: a lack of programmer experience with tests and a general attitude that they are a chore to write. How do you go about training new programmers to write tests?

Thanks for open-sourcing all of this so quickly - I probably spend more time looking over 971's code every year than I should, but there's just so much to learn from it.

[AustinSchuh]

Originally Posted by kylestach1678

My bad. You're right - downgrading to 0.2.2b fixed it. I suppose that's the downside to using a tool like bazel where breaking changes occur every few releases.

And that's why, for work, we upstreamed https://bazel-review.googlesource.com/#/c/2620/ . On my list of things to do is to use that for 971. That way, the version of bazel that is used by a specific git commit is versioned with the rest of the code. That makes it such that you get to pick when you want to upgrade. Bazel is all about trying to version all your dependencies (compilers, code, libraries, etc) such that everyone will get a bitwise identical result. Google does a very similar thing internally.

For others following along, Bazel builds a namespace sandbox for each build step, only providing the dependencies that were specified for each step. This makes it very hard (though not impossible) to write build rules which aren't deterministic and repeatable. I've built code on one laptop, deployed it with rsync, re-built on another laptop, and rsync told me there was no work to be done.

Originally Posted by kylestach1678

Now that I've gotten to take a better look at the code, I'm amazed (as usual) at the sheer amount of testing code present. 1335 lines of code in superstructure_lib_test.cc ! How are you able to get people to actually write automated test code? We've been trying to make unit testing a more important part of our development process, but this past year we weren't able to make that happen as much as we would have liked for two main reasons: a lack of programmer experience with tests and a general attitude that they are a chore to write. How do you go about training new programmers to write tests?

Thanks for open-sourcing all of this so quickly - I probably spend more time looking over 971's code every year than I should, but there's just so much to learn from it.

1335 means we've gotten better at being more concise The real measure is number of test cases, of which I think there are 29 in that file. That's more than we've had before. We write what I would call more integration tests than unit tests, but I've never really been happy with any definitions I've come across.

We are really big on testing as a team, and I think that helps. I view the season as a success if I can get the students to believe that testing is and should be a required part of development. When new students come in, the older students and mentors focus on testing. Heck, that's one of the ways we'll get new students to start to contribute. "Please write foo and add a test for it." isn't an unheard of request, or "I think there may be a bug here, can you test it to see?". Everyone writes tests (I probably write more tests than most), so that prevents it from being a new kid thing. We have mentors who have a lot of experience in industry, and help make sure the code is designed to be tested. We also look for tests as part of the code review process. I'm much more willing to merge a commit if it has tests. (There are a small subset of people who have the permission to do the final submission for code that goes on the robot. This helps keep the code quality up and keep the robots functioning.)

A lot of that stems from us building complicated robots requiring complicated software. It is hard, if not impossible, to write complicated software without good testing. A lot of the bugs we've caught in testing would have destroyed our robot when we turned it on. We also start coding week 3, and finish assembling and wiring with only a couple days left in the build season. Good testing lets us start writing code before the hardware is available, and test out all the tricky corner cases that either rarely come up in real life, or are really hard to tell if they are performing correctly. I won't let the robot be enabled until we have tests verifying that all the traditional problem spots in the code work (zeroing, saturation, etc). The end result is pretty close to 100% line coverage, though we don't bother to measure it. This makes testing a required part of our robot code. Our intake this year took 0.35 seconds to move 90 degrees with 1/2 horsepower. If something goes wrong in that code, you can't disable it fast enough to save the robot. That's pretty scary, and really gets you to think twice about code quality.

Honestly, one of my favorite days of the build season is the day when we run the code for the first time. There are normally a couple tuning issues, but nothing really major, and the code tends to "just work". It is a very deliberate process of verifying that sensors all work, then verifying that the motors all spin the right direction, calibrating all the hard stops, soft stops, and zero points, and then slowly bringing the subsystems up with increasing power limits. I like to make sure people come for the robot bringup, since it really shows off the power of good testing.

My experience is that resistance/hesitation to test code comes from it both being hard to do, and something that isn't strictly required for small projects. If you want to write good tests, you need to design your code so that you can do dependency injection where needed, and expose the required state. This takes explicit design work up front. The problem is that for small projects, testing slows you down. You can run the 3 tests manually faster than you could write the test code. As the project size and complexity grows, testing starts to pay back off. FRC robots are on the edge of requiring tests.

Integrating good testing into your team is as much a knowledge problem as a cultural problem. There's a classic story where a major web company was unable to make a release of their product for 6 months because they weren't sure that if they released it, it would work. They couldn't risk it. They fixed that by hiring people to turn the culture around, training everyone on how to test and the importance of testing. You need to have your mentors and leaders buy in to automated testing, and drive it. They need to lead by example. Take your code from this year, and figure out how to modify it to be testable, and then go write some tests for it.

[Tom Bottiglieri]

Originally Posted by AustinSchuh

Most of the CPU on our robot ... into WPILib (50%).

[Greg Woelki]

Originally Posted by AustinSchuh

Yes. Every hex shaft in the 3 gearboxes that matter is custom sized to be about 4 thou oversized. The gears are a light press fit on the shaft.

We also run the first reduction as a well tensioned chain run. The chain has negligible backlash when well tensioned. You do need to tension it enough such that it doesn't go slack under acceleration and deceleration, or you add nonlinearities back into the control loops again...

Apparently you can do similarly good things with a soda can as a shim, or some other thin metal. We haven't tried that ourselves.

How do you go about manufacturing the oversized shafts? Also, how tight are the interference fits? Hand tight? Arbor press tight?

[mr.roboto2826]

How did you guys go about the development of your 2 (side by side) wheeled shooter? From the outside looking in it looks fairly simple, but I would assume hours of tweaking went into it. Could you enlighten us as to how the shooter went through its development stages?

[AustinSchuh]

Originally Posted by mr.roboto2826

How did you guys go about the development of your 2 (side by side) wheeled shooter? From the outside looking in it looks fairly simple, but I would assume hours of tweaking went into it. Could you enlighten us as to how the shooter went through its development stages?

We have a couple pictures on our Picassa page, but the story helps tie them together.

We did a bunch of CAD sketches to try to determine packaging. We quickly discovered that to make it all package like we wanted, a side-by-side wheel shooter helped a lot. That info was then fed to the prototyping team, and they set to work.

The first job was to build a CIM + wheels module. By random chance, we picked 1 CIM and 2 wheels. Based on some old math, we picked a reasonably high surface speed, and machined the module on the router.

We then attached the module to a bunch of 8020, and started doing a parameter sweep.



The obvious parameters (for us) to try were compression, and surface speed. Once the shooter was making shots into the goal reliably, we started collecting ball landing position data. They were using a pulse counter on the Fluke multimeter and reflectance sensor to count RPM to dial the RPM in accurately for the tests.



As you increase compression, there is a compression level where the spread shrinks, and then starts to increase. We picked that point.

The prototyping team didn't the standard deviation was quite good enough, so they kept working at it. Someone came up with the idea to offset the wheels vertically to put a little spin on the ball. That reduced the spread far enough that they were happy with it, and we shipped it with those numbers exactly. We haven't had to touch any of the shooter parameters all season, which is wonderful.

[mr.roboto2826]

Originally Posted by AustinSchuh

The prototyping team didn't the standard deviation was quite good enough, so they kept working at it. Someone came up with the idea to offset the wheels vertically to put a little spin on the ball. That reduced the spread far enough that they were happy with it, and we shipped it with those numbers exactly. We haven't had to touch any of the shooter parameters all season, which is wonderful.

Would you be able to go in depth a little more as to your prototyping process and iteration? I noticed in the photo you had a rail on the bottom of your shooter, but your final design had none. Also could you explain the pneumatic setup on your feeder into the shooter?

[Travis Schuh]

Originally Posted by Greg Woelki

How do you go about manufacturing the oversized shafts? Also, how tight are the interference fits? Hand tight? Arbor press tight?

We shoot for what I think is described as a transitional fit (+- a couple tenths off of nominal). We used to just sneak up on it and test fit it, but this year we got access to an optical comparator at a sponsor's lab and measured the hex size on the 1/2 hex VP broach to be ~ .5045 and the 3/8 hex VP broach to be ~.3765 (I would verify your own numbers if you choose a similar route). We ended up needing a light press to assemble, but it was easy to remove the parts when we did end up having to change a ratio. One trick we found was that it is important to put a radius on the edges of the hex to account for the radius on the broach. The numbers we cut to should be in our CAD.

We machined them using a 5C collet fixture on a HAAS mini mill (PN 3174A42 on McMaster or equivalent). This puts the shaft vertically. We machined it primarily using with a 2" LOC 1/2"D carbide endmill, and designed the shafts so that they could fit in two setups of this. We started with 5/8 precision ground 7075. We would start with a blank of known length (so we could use collet stops), machine one side, flip it over and hold onto some section that was either previously machined or a section that was designed to be left un-machined, and then machine the back side. Last year we started using slitting saws to put the snap ring groves in during the same operation, and that has been a nice time saver. Another trick we learned is it is really worth while to have a finisher endmill that you use just for the finish pass so that you don't end up with the bottom of each profile being a little tight due to the end of the endmill being more worn. We haven't had any issues of runout, although it is a concern.

Overall, I estimate that we spend 1/2 to 3/4 of a day machining all the critical shafts for both robots. The setup and CAM changeover goes relatively quick once the first part is setup. We find the time savings on the design and fiddle factor to be worth the effort.

[Gregor]

Your last 3 robots have been extremely ambitious, unique, and well done. Why are your robots so different, what are you doing that's different than other teams? During brainstorming when someone proposes something like your 2015 robot everyone would throw it out immediately. How do encourage such unique thinking, and when you move into the design process how do you know you'll be able to pull off your crazy robots?

[AustinSchuh]

Originally Posted by mr.roboto2826

Would you be able to go in depth a little more as to your prototyping process and iteration? I noticed in the photo you had a rail on the bottom of your shooter, but your final design had none.

The rail in our prototype was to help feed the ball in consistently. It was added quickly after hand-feeding proved to be not reliable enough.

We started by controlling every variable possible. Once we had something that performed well enough, we started looking at the CAD and what the final solution was going to look like. We then measured the prototype and tried to make the model match. Whenever we found a place where we wanted the model to diverge from the prototype, we tweaked the prototype to match the proposed design and re-ran our tests. Our final design has a plate holding the ball until it is grabbed by the wheels, which serves the same purpose. We pulled the bar back until it was just about as long as the final design wanted, and verified that it still worked.

Originally Posted by mr.roboto2826

Also could you explain the pneumatic setup on your feeder into the shooter?

That piston linkage alone took an entire weekend of work. Open up the model and take a look. The left-right spacing is killer, especially since you want a ~3 pound grabbing force.

This year was different in that you didn't need to shoot multiple balls. We chose to use that by designing a shooter to hold one ball very securely and load it very consistently. That pointed us towards designing something which grabbed the ball in a "cage" with pistons and linkages, and some sort of piston loading mechanism. After a couple conceptual iterations in discussions, someone proposed having 2 links where the links were driven relative to each other to grab and release the ball, and the pair of links rotated together to feed the ball into the flywheels. We very carefully worked through all the geometry in solidworks sketches, figured out all the components, and then worked on finalizing the design. We tried at least 4 different piston models before we found a piston that would work.

I'm not sure I explained the pistons the best. Ask for clarification where I wasn't clear enough.