Just fyi. Not starting a flame war. Just a gripe.
Limelights cost $400 dollars.
Can we get a vendor dependency instead of a file that we drop into our code with static methods.
Feels a bit cheap. Especially for such an expensive product. Having stray external files in the codebase just looks like a wart to me.
The file doesn’t even have JavaDocs
LimelightLib is not worth your time, unfortunately you’re better off writing your own library for it that actually uses things like OOP, rather than just a million static methods.
It’s kinda ridiculous
Yeah. Better to just read their Network table’s api and roll your own class
We are transitioning to PhotonVision this year, but still have LL’s. I suppose we can flash them to use PhotonVision instead of LimelightOS
I do agree that it’s ridiculous that you’re paying 400 dollars to get no library, and also be locked into closed source software, when you can spend ~$140 on an opi and camera, use photon vision, and get a really good library with simulation capabilities, and be able to add functionality, help fix bugs, etc
Counterpoint: Having an optional static lib that gives you the flexibility to build on top of it to fit your codebase is nice. Not everything needs to be unnecessarily OOPified. The static lib is completely optional, very functional, and simple to use. If you want your own API for it, it gives you the flexibility to make one yourself instead of making underlying assumptions about what your codebase will look like and shoehorning you into a design style that may not fit your codebase well
I agree in principle, it’s must the odd one out and looks and feels weird.
Frankly, a solution isn’t a good solution if the only reason for it is that everyone else does it. Although initially I was curious/surprised it wasn’t packaged as an external vendor dep, we have successfully used it and are generally* happy with it. The students understand the usage pattern, they can look at the underlying code, it’s easy to update - not more we could want.
*The Jackson JSON parser is my only gripe - it has some quirks that aren’t ideal, but not a huge deal in the grand scope of things.
Having a Limelight just for Photonvision is unnecessary, ridiculously expensive, and limited in terms of capabilities. I’d recommend just getting an OrangePi with an external camera and have far more potential.
Keep in mind they specified they already have the hardware, so there’s really no point in not utilizing it, unless they need the extra performance a traditional OPI5 + OV(xxxx) camera would give. If the team were to purchase new hardware, I would agree with your recommendation.
I believe one of our students tested a different parser for faster speeds, I don’t recall if we ever had any hard evidence to suggest it worked better or worse. Can check in at our next meeting if there’s time.
If I remember correctly, the Limelight 3 was based off a RPI Compute Module 4, and when we tested it out with Photonvision the performance was around 12 fps for 800x600 resolution. Although I suppose it is unnecessary to buy new hardware, I’d still recommend it. I get your point though.
A history based explanation: The initial usecase of limelight (yaw of green blob in the camera feed) was so darn simple that a vendor dep to read one NT double entry was pointless and distracting. It’s only in the age of apriltags and megatag-style pose estimation that getting multiple numbers back atomically and decoding poses that the code gets complex enough to need some thought.
A business based explanation: People are currently buying them like hotcakes, despite the not-as-polished interface. Unless you can show it impacts the top line, why invest in the creation and maintenance of a formal vendor dep? Sounds like a bunch of darn nerds making things too complex 
To be fair, vendordeps are nontrivial to write, build, and publish. Copy-pasting one file is a lot easier. Function documentation would still be nice though.
I disagree, LimelightLib is minimal which gives you the flexibility of using it however you want in your codebase, you aren’t forced into any design style. You can also write your own libraries on top of it.
I don’t think it really needs a JavaDoc either, as the library is essentially a couple wrapper classes around the NetworkTables API. If you need to know how or what a function does, you can just look at the source code.
The NetworkTables API isn’t self-explanatory either. At minimum, it should document the units and coordinate frames used by the data provided.
The whole purpose of an API, and abstraction in general, is to not need to look at the library source code to know how to use it. If users have to look at the source code, your design and documentation have failed and you’ve wasted the user’s time.
All very good points in one way or another folks.
My personal view is when I see a project or sample project with LimelightHelpers.java in it for some reason it just triggers my OCD.
If I’m paying $400 for a solution that prides itself on being easy, I expect a proper API, not just a jank single static file.
The money I’m paying should be going towards developing an API in addition to the onboard software. I don’t buy the “the static file gives you more freedom and is simple” argument. A well designed API can be too. Again, when you get a Limelight, you’re paying for the proprietary software on it, and an API is part of that equation.
Limelight has just gotten complacent, and I certainly hope that they learn a thing or two from PhotonVision, or they will rightfully be crushed.
And it will be IMO one of the best triumphs of open-source over proprietary software I’ve seen.
Photonvision is better in every way
Literally couldn’t have put it better myself.