I understand. However, I’ve had very similar experiences with industrial cameras and sensors in a research setup.
Taking snapshots was ok, once you had setup everything (it only worked with GigE Network cards supporting jumbo packets and some other specific settings) and used their “acquisition” software (which could be automated). However, triggering multiple cameras at once at the exact same time was a similar experiences with additional trigger lines and multiple discussions with the manufacturers application engineers.
Even worse where non standard sensors line photosynthesis sensors or other industrial sensors used in a non standard setup. For the lidar I also had to read their hundreds of pages long documentation of their serial interface but send it via TCP in special packets which had almost no documentation. Depending on the command the byte order also had to be swapped which was not documented at all and I had to find it by trial and error.
For a different laser sensor that produces point clouds there was a simple interface to get preprocessed images but we wanted the raw point cloud data which also required to download the files from an on-device FTP server which also required so some guess work.
Later I worked in industrial settings with PLCs and these guys sometimes also go overboard with complex setups (I’m looking at you, Siemens RFID reader…)
So I’m not sure if it’s the military grade that makes it such an experience. Industrial grade seems like a similar experience. I guess a lot of consumer devices also do shit like that under the hood but hide it in firmware and drivers.
However, triggering multiple cameras at once at the exact same time was a similar experiences with additional trigger lines and multiple discussions with the manufacturers application engineers.
100% this; synchronisation challenges are the bane of my existence. There are also a lot of cases when it would have been really helpful if data output from a device were timestamped (even with something incomplete like “number of milliseconds past the minute”), rather than having to timestamp it on receipt and make some iffy assumptions about latency.
Depending on the command the byte order also had to be swapped which was not documented at all and I had to find it by trial and error.
“Determining endianness is left as an exercise for the reader” type logic, honestly lol.
So I’m not sure if it’s the military grade that makes it such an experience. Industrial grade seems like a similar experience.
It’s quite plausible (and disappointing to hear) that it’s a broader issue with industrial grade hardware; my own experience is limited to products specifically aimed for military/defence applications.
I guess a lot of consumer devices also do shit like that under the hood but hide it in firmware and drivers.
Yep, but I think there’s also a broader point about work that is niche or “cutting edge” versus industry standard. The example that comes to mind is the quality of code written in academia versus in industry, the former often being significantly worse. I think part of it is that code quality is far less emphasised compared to the higher level technical concept it’s used to demonstrate. I honestly believe that a sizeable chunk of the professors and lecturers from my university would struggle to produce work that is “up to standard” in a regular software eng role, at least initially.
I understand. However, I’ve had very similar experiences with industrial cameras and sensors in a research setup.
Taking snapshots was ok, once you had setup everything (it only worked with GigE Network cards supporting jumbo packets and some other specific settings) and used their “acquisition” software (which could be automated). However, triggering multiple cameras at once at the exact same time was a similar experiences with additional trigger lines and multiple discussions with the manufacturers application engineers.
Even worse where non standard sensors line photosynthesis sensors or other industrial sensors used in a non standard setup. For the lidar I also had to read their hundreds of pages long documentation of their serial interface but send it via TCP in special packets which had almost no documentation. Depending on the command the byte order also had to be swapped which was not documented at all and I had to find it by trial and error.
For a different laser sensor that produces point clouds there was a simple interface to get preprocessed images but we wanted the raw point cloud data which also required to download the files from an on-device FTP server which also required so some guess work.
Later I worked in industrial settings with PLCs and these guys sometimes also go overboard with complex setups (I’m looking at you, Siemens RFID reader…)
So I’m not sure if it’s the military grade that makes it such an experience. Industrial grade seems like a similar experience. I guess a lot of consumer devices also do shit like that under the hood but hide it in firmware and drivers.
100% this; synchronisation challenges are the bane of my existence. There are also a lot of cases when it would have been really helpful if data output from a device were timestamped (even with something incomplete like “number of milliseconds past the minute”), rather than having to timestamp it on receipt and make some iffy assumptions about latency.
“Determining endianness is left as an exercise for the reader” type logic, honestly lol.
It’s quite plausible (and disappointing to hear) that it’s a broader issue with industrial grade hardware; my own experience is limited to products specifically aimed for military/defence applications.
Yep, but I think there’s also a broader point about work that is niche or “cutting edge” versus industry standard. The example that comes to mind is the quality of code written in academia versus in industry, the former often being significantly worse. I think part of it is that code quality is far less emphasised compared to the higher level technical concept it’s used to demonstrate. I honestly believe that a sizeable chunk of the professors and lecturers from my university would struggle to produce work that is “up to standard” in a regular software eng role, at least initially.