Team 2122 is happy to publicly release the code for our 2017 offseason robot, Limbo.
Some highlights include:
All of this, and more, is available at the github repo: https://github.com/Team2122/Limbo-Public
Thank you for viewing our code. If you have any questions, don’t hesitate to ask.
Thanks for sharing! That auto 9122 ran to pick up 2122’s dropped gear, place it, and then shoot 10 balls in CCC elims was incredible! Any chance we will see some pictures or documentation about the building of that offseason bot?
Congrats on another great season!
We’ve been waiting for this. We’ll definitely scour your code to see how you made that 2 gear auto!! 
See you in Idaho!
Interesting Gradle configuration. Why roll your own buildsrc plugin?
EDIT: hmmm
It looks like your kotlin vision code was running on a raspPi, how was performance?
Sorry for the late reply.
It looks like your kotlin vision code was running on a raspPi, how was performance?
Our vision system performs well enough, and we don’t typically see any problems with low frame rate.
Interesting Gradle configuration. Why roll your own buildsrc plugin?
We initially used GradleRio once we made the switch to Java, but we quickly had some problems with it and ended up writing a nice long build.gradle for our competition robot, and ultimately cleaned it up and rewrote it as a plugin for the off-season.
It’s worth mentioning that our autos are not in code at all, but rather in our config/Commands.yaml file. I believe you’re looking for AutoTwoGearRed and AutoTwoGearBlue
See you there
If you’re having issues, chances are others are. You can help get them fixed by opening an issue on the GradleRIO repository. Can’t fix bugs I don’t know exist.
Can I ask what camera you’re using? Do you know typical frame rate for your system? Or how long your typical vision pipeline takes to process each frame?
We’ve used Kotlin for the robot for a while now, but just started playing with Kotlin for vision instead of C++, so it’s interesting to hear from a team that has already done it.
We didn’t really encounter any bugs, but it was more about being able to deploy configs and code separately, which is pretty much only useful to us, I would think.
You don’t need to rewrite GradleRIO to do that. We also deserialize from YAML using Jackson, and we use GradleRIO to deploy our code and the hidetake(?) ssh Gradle plugin to copy over .yml files. Look at the copyResources task here.
Figured I might as well reply to some things that I would be more familiar with
The initial reasons that I remember for why we wrote our own plugin to replace GradleRIO:
A lot of this is specific to our uses, and may have changed with GradleRIO since we’ve used it (I haven’t looked at it much recently). Your plugin did provide a lot of the inspiration for ours, and I really do appreciate the work you’ve done on it.
We either a Logitech C270 or Logitech C310 camera (whatever we can get our hands on). Mostly chosen based on price and availability. Since what I’ve found is most important for vision cameras is reliability, low resolutions, and low latency, this probably isn’t the best choice (we are investigating other options)
Typical frame rate is 25-30FPS running at 320x240. (this is with running 2 cameras, but we only ever capture from one at a time)
Actually processing each frame (with the resolution & algorithm we use) doesn’t take very long (<33ms, even)
As for using Kotlin for FRC, I don’t have too many complaints. It takes roughly 50% longer to compile than Java (:rolleyes:). The biggie for us is that it’s more complex (I’ve definitely written somewhat opaque code in it) and has a longer learning curve, which is why we do not use it for our main robot code. Personally, I do like the language more than Java
I will caution against writing vision code in any JVM language. It doesn’t perform as well (from a startup time & latency standpoint) as C/C++, and it makes it harder to use lower level APIs for capturing & configuring cameras. Using OpenCV’s VideoCapture and v4l2-ctl mostly worked for us, but it had reliability issues which prompted us to investigate other options.
Thanks for all the info! We used Python for vision in 2016 and then C++ in 2017, but our programmers wanted to use a single language this year, so we’re testing Kotlin. Currently we’re also using VideoCapture, and we wrote a V4L2 wrapper for Kotlin to allow changing camera settings on the fly. We’ve been using a Playstation Eye camera since it’s less than $10 and goes to 60 FPS at 640x480 or 120 FPS at 320x240.
Do you think you all will stay with Kotlin vision for 2018?
e.g:
deploy {
artifacts {
fileArtifact('myCustomFile') {
file = file('myFile.txt') // relative to project directory
filename = 'myRemoteFile.dat' // optional
targets << 'roborio' // or whatever your target is called
// other properties available (see EmbeddedTools)
}
// You can also use fileCollectionArtifact for a group of files
}
}
GradleRIO won’t deploy libraries if they are already up to date. It does a cache check. You can change its behaviour in the artifact config (the changing of behaviour is new, but the cache check has been there since late 2016).
GradleRIO has a task for each artifact (java + native + libs + robotCommand + others). You can see them typing gradlew tasks --all (it doesn’t display in the condensed task list). No matter if you deploy some, one or all artifacts, GradleRIO will reuse the same SSH session (we only use 1 SSH session for each build).
There’s no reason you can’t do this in your build.gradle file already. For JVM flags, you can pass those flags directly to the FRCJavaArtifact.
Fair. There’s a lot of effort going on to make GradleRIO as flexible as possible, but I guess the satisfaction of writing your own plugin can’t be gained in that regard, unless you develop a companion plugin. Regardless, don’t forget to reference/credit code used from other projects, at first glance a lot of areas look very familiar.