SWEET!!! I’m trying to move our programmers towards Test Driven Development. I had some issues dealing with WPI and unit testing on a laptop. I’m looking forward to looking at your code to see how you isolated WPILIB so you could unit test.
Some of your documentation references advanced control theory concepts. How do you teach these things to students? Are there any good resources that you’d recommend for someone who would like to learn more - especially someone whose control theory expertise begins and ends with PID?
The students can reply with specifics, but the quality of our code is dependent on our peer to peer teaching model. 1678 has no software mentors, so it is critical that our older students pass their knowledge down effectively to the next generation.
I won’t say that we wrote it just for Adam’s reaction - there was also something about auto modes needing to actually work - but I also won’t say it isn’t a nice benefit .
The WPILib interface is in “c2018/wpilib” and contains all of the actual calls to WPILib. It reads outputs from message queues (and writes sensor values), which are essentially locked ring buffers. As you mentioned, this lets us unit test everything - it’s nice to be able to rewrite code at competition and have it work without breaking the robot, and comprehensive unit testing has allowed us to do that. I’m a huge fan.
I’ll preface this by saying that our process is constantly changing, and we definitely haven’t narrowed in on a method that works perfectly. That said, our process this year was, in my opinion, the smoothest it’s ever gone (especially considering that (a) we have no programming mentors, so we had to run everything ourselves, and (b) we had a massive amount of programming students this year). We first taught the new students Python, using a curriculum that we developed over the summer - this emphasized the concepts without letting people get hung up on syntax. Then, about halfway through the offseason, we transitioned them to C++, mostly explaining syntax at this point. After they got the hang of syntax (to a point that it was workable - we hand-waved templates as “magic” to a degree), we got into the meat and bones of robot-specific programming - architecture, control loops, mechanisms, etc. For the first few weeks of build season, before we have a robot, most of our time is spent actually writing new code. During this time, we divy up the work by pairing up experienced members with new members and pair programming. Again, all this said, a lot of the work (more than I’d like, to be honest) was done by experienced (year 2+) students.
Like I said, a lot of the code this year was not written by new students. This includes all of the control theory - it’s nearly impossible to teach someone who hasn’t taken calculus concepts from Calc I, Calc II, linear algebra, and differential equations in a single offseason. Most of our students who understand these concepts put a ton of work in over the offseason to self-study, and practiced implementation on our offseason robot. In terms of resources…well, to be honest, I’m always looking for better resources to teach these concepts too. I’ve found UMich’s pages to be a pretty helpful resource, and one of our alums created a few blog posts that are basically equivalent to how I teach interested students.
We love to steal from the best and invent the rest. When it comes to controls, 971 is the best. Besides the resources I mentioned above, the single most helpful resource I’ve used for learning some of this stuff is reading through 971’s code. For learning state-space modelling and control, seeing a practical implementation can really solidify understanding in a way that’s hard to do with just theory. We use a version of their drivetrain code, although we’ve modified it to support a few extra features (path reparametrization/following being the big one). The monorepo structure is another technique we’ve borrowed from them - it gets around versioning issues with our year-independent libraries (muan) and lets us check new code against old codebases. Still, it can be a bit of a pain, and I’m somewhat torn on whether or not it’s a net benefit.
Bazel is much, much faster (almost 20 times faster). Since our code is so large (nearly 6K lines of used SLOC) the difference is very noticeable. It’s integration with Google Test, easy to read BUILD file syntax, and integration with protobuf (especially protobuf) make it a must. Skylark is also nice, as we’ve been able to make a generic build/deploy system.
The only really annoying bit about Bazel is cross-compiling. Bazel’s CROSSTOOL setup can be a real pain, although we have a reasonably funcional setup currently. Since Bazel is still coming out of beta, there are breaking changes more often than you might get with Gradle (although these have been mostly easy to fix).
Tim, you seem to have strong enough opinions since you’re taking pot shots at 1678 in a thread where they’re sharing their work and resources with the community.
I’m not interested in derailing this thread further, but the data you have is incorrect. 624 declined 1648. If you’re pulling this from TBA, know that the declines field is not accurate - it’s always blank.
Kyle, et. al., I have a few follow-up questions for you:
There’s been some discussion on Github about unit-testable WPILib for 2019. Do you anticipate that 1678 will migrate to the WPI approach if they release it?
Like I said, a lot of the code this year was not written by new students. This includes all of the control theory - it’s nearly impossible to teach someone who hasn’t taken calculus concepts from Calc I, Calc II, linear algebra, and differential equations in a single offseason. Most of our students who understand these concepts put a ton of work in over the offseason to self-study, and practiced implementation on our offseason robot. In terms of resources…well, to be honest, I’m always looking for better resources to teach these concepts too. I’ve found UMich’s pages to be a pretty helpful resource, and one of our alums created a few blog posts that are basically equivalent to how I teach interested students.
I absolutely love those resources you’ve linked. Thanks for sharing. Do you have any idea when Wesley will finish his control theory articles? What resources do you use to teach Kalman filters?
There was the threats of “I have a Zippo and I’m not afraid to use it” that affected the alliance selection process. Teams below us made it plain they would not accept offers from us, which, silly noobs that we were, we believed. In retrospect, we could have scorched the field below us. What is the difference between 2 in alliance 4, and captain of alliance 7? As it turned out, not much.
All honor from us to RAWC (968), Fernbank Links (4684) and Lancer Robotics (2367). Thanks for playing with us, we played hard, together.
More crap tomorrow about sending one’s second string scouting team out to point out that “your advances are not welcome.”
.