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?
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.
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:
We had to deploy our YAML config in addition to our robot code, and we wanted it to deploy completely separately from code
We wanted to deploy all of the libraries we use separate from our code .jar file, to save space/network traffic/flash r&w when we deploy code
GradleRIO only has (had?) 1 task for deploying, and we wanted more granularity than that
We wanted to be able to deploy in multiple configurations (mainly for changing JVM flags for debugging)
We (mostly I) like flexibility and wanted to learn how to write gradle plugins anyways
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?
You can deploy arbitrary files with GradleRIO. Beforehand, this was done through deployment configs (early 2016+), but now you can use the backing library EmbeddedTools to add your own artifacts. You can even create your own Artifact types if you have some special logic to do during the deploy phase, as shown by GradleRIO’s added FRCJavaArtifact and FRCNativeArtifact.
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.