Why so much limelight hate?

FIRST
, ,
1

I was reading the thread for the new robot controller announcement and saw that many people were disgruntled with the fact that FIRST chose limelight over photonvison. I mainly work on the hardware side of things and from what I gathered from our programmers, they like limelight too. We used both photonvision and limelight’s on our robots this year and I found that both were nice to use. So why is there so much disgruntlement with the decision to go with limelight?

What vision system do y’all use?

  • Limelight
  • Photonvision
  • Other
0 voters
5 Likes
2

They went completely radio silent (no emails, no CD, no nothing) on everyone for the first month of build season last year, and are yet to acknowledge that failure, let alone explain how it won’t happen again. When you consider that in a few years there will be an order of magnitude (not exaggerating) more teams to provide product support for, I’m concerned.
That, combined with their increasing reliance on generative AI to write documentation and provide support has me very concerned about the quality of support that will be available to the teams that need it.

31 Likes
3

From what I’ve heard, most of the disgruntlement is from the fact that limelight is closed source, has had very skimpy documentation, and charged a ton for their products where most of the price comes from their proprietary software. For first to choose a company that is both closed source and bad at documentation raises a lot of eyebrows towards how the final control system will turn out.

9 Likes
4

This is the equivalent of asking “why choose Google instead of Mozilla to make a phone”. Just because they both make web browsers does not mean that they have the same capabilities or even interest in making hardware.

FIRST didn’t choose a vision software provider, they chose someone that makes hardware to make the next MRC. Photon is none of those things. A valid question might be to ask “Why choose Limelight over WCP / Redux / REV / CTRE / Andymark” etc. Companies who actually have experience making hardware.

Anyone questioning why FIRST chose Limelight instead of Photon fundamentally doesn’t understand the difference between hardware and software.

Not to mention the fact that Photon didn’t even enter a submission to the RFP from FIRST for the MRC, since… u know, they are a (small) group of people who work on a vision software during their limited free time.

90 Likes
5

Or didn’t understand at first that Limelight was doing the whole system and not just an onboard vision processing module.

16 Likes
6

I think the question was not "why the LL was chosen, but rather why that decision was met with “hate” from some members.
I completely agree that LL is an established hardware maker (in addition to the software), and Photonvision is not. I also think that after the early silence last year, they really stepped up, including off-season activity this year. I do not know if it was related to that decision, or because they simply had resources available, but bottom line - I think they have a decent product and a desire to produce it commercially in sufficient quantity to cover FIRST needs.

So, I agree with your assessment, and I think out of the options available (at least the ones I am aware of) LL covered all points necessary for this decision, despite some shortcomings indicated by others.

2 Likes
7

PhotonVision isn’t “not an established hardware vendor”, they’re not a hardware vendor. It’s a community project that as far as I know barely has test hardware, much less a legal existence as a corporation with the resources to even strive for such an effort to submit for the CS RFP.

Limelight the company was selected in conjunction with other companies as the provider, not Limelight (the vision appliance). Their behavior and product (the vision appliance) as a proxy for how the company will behave in the role of Control System provider is a reasonable one, but can cause some confusion.

Please take care so folks don’t get confused, thanks!

26 Likes
8

A couple of users complained very loudly and repeatedly and insistently. I noticed that their commentary started before sufficient details were released to even begin to understand the arrangement. My CD block list has grown.

I wouldnt put too much stock in the CD react-posts. Sure, there will be concerns and issues… No vendor will be perfect and Limelight (the company) is positioned to provide a sufficient solution at a radically lower cost. I’m looking forward to what @Hjelstrom and team build for all of us.

22 Likes
9

Paying for software isn’t inherently a bad thing. For advanced users, sure, they’d rather have more control over what they are doing, but for a majority of users, by paying for the software, they get something that just works with minimal time investment. This is evident by even top-level teams using limelight, when they have the resources and experience to make whatever they want work, but yet, they’d rather pay for the software that works. For a vast majority of teams, having a built-in vision solution that works with minimal tuning or experience, (along with limelight making hardware) is a huge benefit.

I’ve rarely seen the “open source or die” mentality get people anywhere. We’ve seen people hate on Bambulabs for this same reason, yet, they are the best printers you can buy on the market by a long shot for many reasons. Most of the software you use on a regular basis is closed source, and many of them are quite pricey, and yet they (usually) aren’t bad, and don’t get this level of scrutiny on announcement.

6 Likes
10

sounds like a certain company that makes motor controllers…

Anyway, I think a lot of people misrepresented limelight’s role in the product development (as to the photon question). Others were skeptical of limelight’s ability to scale. I think given they just hired a couple more EEs, they’ll probably be ok, especially since they have a couple years to finalize supply chain things

1 Like
11

I think you (or the people you are talking about) have a fundamental misunderstanding on how products work.

When evaluating the Limelight team holistically across all the years they have been active, that was anomalous - after that period, pre comp, they came back in full force with lots of support and updates.

16 Likes
12

For us, it’s cost. You can get yourself a pi 5 running photonvision coupled with an OV9281 camera for about half the price of a limelight. On top of cost, the more custom-made solutions generally outperform limelight in every conceivable way.

6 Likes
13

First, just gonna say im not gonna address the MRC stuff, its still way to early to pass any judgement beyond the purely reactionary.

Second, every solution has strengths and weaknesses, for all I love about PV, its still (only if marginally so) more complicated to set up then limelight and (by virtue of its mostly hardware agnostic nature) can at times have some issues LL does not. LL on the other hand is limited in both performance and features while still being quite costly. You can get more out of PV, a lot more in my opinion, but it will take a bit more effort.

We use PV for apriltags and a custom solution for ML because this is the setup that works well for our unique combination of needs, capabilitys, and desires. This will not be the case for every team.

Weather it be a CUDA accelerated depth camera or plug-and-play limelight, or anything in between, us what works for you!

4 Likes
14

Just a small note: PhotonVision is solely a software solution, and many teams run it on Limelight hardware. FIRST didn’t “choose” between the two. I’m almost 100% certain that, when the new controller comes out, Limelight’s software AND PhotonVision will still be the two most popular choices for vision software.

13 Likes
15

“charged a ton” - I’ve got experience designing an building hardware products. As the creator, you bear all the cost, up front - you either borrow it or forgo other activities with that money. Hardware for prototypes costs money (those vendors want to be paid up front), each hardware spin costs money, long term software development costs money, enclosures cost money, applicable testing like FCC compliance costs thousands of dollars - all up front.

As a small, specialized vendor, you tend to get hammered by your suppliers, you either don’t have the volume at all or you don’t have the money to afford the volume that you could get.

It costs a lot of money up front. Money that you could have been doing something with but feel like you can get a better return doing this - over time - which also impacts your return - all with risk piled on that.

I’m not trying to beat you up but there is a lot going on to design, manufacture and sell these products and it all costs money. The Limelight folks aren’t making a gazillion dollars on each of these and when they go through a distributor like AndyMark, they get even less because the distributor wants to sell it for no more than than what you are selling direct (all with the hope of more quantity).

All for something that costs $400 (the price of 2 Krakens today).

For me (both here in FRC and professionally), this all boils down to “Do you have a $X problem?” (where $X is the cost of something - the total cost). For some folks the answer is “no” and that’s OK. For others, it’s “I have a $10,000 problem; I can fix it for $2,000? I’m in!” (probably not FRC but talk to a commercial customer with a real issue and that sort of magnitude is not uncommon).

I don’t think it’s fair to slam the cost of the LL - I think it’s relatively cheap, relatively sophisticated, and selling into a relative small and very cost-sensitive market - I’m glad they are doing it. Yeah, I’ve used both LL and PV (and even Chameleon before that); it’s not like the non-LL solutions were like falling out of a tree by the time mechanicals, power, and other things were taken care of - all time that I didn’t have available spend on something else to save some money (or so I thought).

It’s all some sort of arbitrage all the time - this for that…

25 Likes
16

Let’s be hopeful that LL current shortcomings have nothing to do with the future.

We are skeptical of LL abilities because my team’s experience shows that the limelightvision.io home page is completely misleading marketing hyperbole for the usage of AprilTags.

Their robot pose code is pathetically simplistic and unusable (at least, as is). There doesn’t appear to be any hope for MegaTag2 which was billed as saving the day from previous pathetic versions of pose calculations.

The programmers and drive team made an enormous effort but gave up on MegaTag1 and MegaTag2.

The botpose_wpiblue worked somewhat for simple target alignment but they couldn’t use the pose to update robot odometry.

17

Software wise, Photonvision is much easier to work with. While Limelight is a quicker method to get vision to work. In my opinion Photonvision has much more potential than Limelight if programmers are given enough time. Both have strengths, it more depends on your schedule and robot.

2 Likes
18

I will say the Motor controller docs I’ve read are all far and above the level of what the original limelight docs offered. Unless you mean Nidecs Brushless… Nidec Dynamo BLDC Motor with Controller | For the 2020 season software documentation has been moved to https://docs.wpilib.org. Documentation for KOP items can still be found here. | FRC KOP Documentation this is the most comprehensive guide I’ve found on it for FRC.

I dislike the AI reliance for documentation when the original docs weren’t amazing exactly. Time will tell if I’m just worrying for nothing.

1 Like
19

What issues were you actually having? For my team it was very reliable.

4 Likes
20

Since I’m getting bad reviews I could have been clearer. The hardware is easy to use although a bit dated. It started as a complete package but later the recommendation was to use a VRM power supply which was one of the things we were trying to avoid by using LL.

The software is a disaster and was not zero-code nor inexperienced programmer friendly. It mostly cannot be used for robot pose because of pose fluctuations.

I speak only from my experience but you can note many CD posts wondering how to get the LL (or PV) to work better.

I’d be happy to look at the code from teams that had a wonderful experience with LL and then my team can see were we went wrong.

Edit: and the usable fps that we got weren’t anywhere near the LL home page numbers which maybe are theoretical camera limits.