5 ms·

A sensor itself isn't expensive but moving, storing, and processing all of that data to ultimately take action is. Let alone concerns with people about being r

A sensor itself isn't expensive but moving, storing, and processing all of that data to ultimately take action is. Let alone concerns with people about being recorded in public, even if red light cameras are permitted in some states today.

jakecopp 9y ago
Even OpenCV running on a Raspberry Pi can pick out cars in a moving image - a bad offline solution (with a sensible fallback) would be better than a timer. On a large remote setup I think you are right though.
- jakobegger 9y ago
  OpenCV on a Raspberry does not sound like something that is reliable and easy to deploy. It‘s a long way to go from something that you hack together in the living room to something you can deploy on hundreds of traffic lights, that works in every weather, that can easily be configured for different use cases, and that can be serviced by the technicians.
  - jakecopp 9y ago
    You are right. I'm trying to say I think the problem is development bound and not insurmountable (secure, reliable, good fallback to timer) rather than "moving, storing, and processing data" bound as per the parent comment.
    - tedmiston 9y ago
      I agree with you that developing a prototype wouldn't be too hard. But actually rolling it out within a few cities (and getting cities to pay for it) are where I think the complexities lie. I think it's a social or bureaucratic problem more than a technical one.
  - halbritt 9y ago
    It can be: https://resin.io https://resin.io A Raspberry Pi is a surprisingly useful and cost effective device when it comes to IOT. Most industrially hardened devices of similar capacity cost a bit north of an order of magnitude more. There are really only a couple of things that would need to be addressed, a good weather-tight case that allowed for heat dissipation, decent storage (most microSD has a short lifespan), and a good 5v power supply. In many cases, designing a system that is cheap, expendable, and expected to fail is way less costly than the alternative.
    - TFortunato 9y ago
      Sone of what your saying is kind of making the point of the parent though. Yes, you can make the software deployment go easier, and resin looks like an interesting project from that front. But that really is only a small part of the problen, and those hardware problems you described aren't trivial. The testing you described to convincingly show that your device can handle the environmental requirements isn't trivial. (And by environmental, I dont just mean weather, but also things like available power quality, vibration, etc.) These industrial devices aren't expensive just because the suppliers aren't aware of RasPi, or are looking to gouge you. Its because they put in a lot of work to qualify these devices for their intended conditions. The RasPi, hacked up solution might actually be the WAY more expensive option over it's lifetime, if I have to roll maintenance crews every couple of months to replace SD cards or fix a flaky connector. And god forbid our code hangs in a way that makes all of the lights at an intersection green. "Oh you have a way to prevent that? Prove it." Designed to fail works fine for microservices where I can spin up a new instance rapidly, but it isn't the best match for industrial or infrastructure in most cases. Apologies if I'm coming across overly snarky here. I genuinely love the RaspPi, and its got a great niche for prototyping, hacking up one-off projects, or even as the base for many types of connected projects. But I've also worked on industrial and infrastructure types of systems, and more than once I've seen someone say that they've got a cheaper solution to X, when really they've got something that may look cheaper if your only looking at upfront costs, but they are completely ignoring the lifetime costs of the solution.
      - halbritt 9y ago
maxander 9y ago
A traffic light would only need to solve a much simpler problem than an autonomous car- after image-recognition, given the number of cars waiting/approaching at each direction, decide which lane(s) to give a green light to. Finding a reasonably optimal policy could be hard, yes, but once one is found that could be applied to all (or most) traffic lights, and it couldn't plausibly be more computationally intensive to run than the image-recognition step. Meanwhile, if conversation involves a plausible future where all/most vehicles (inevitably including police cars and other government-owned vehicles) are autonomous and have the same kind of sensors, its hard to imagine the anti-surveillance angle being a decisive factor. I'm not for pervasive surveillance, and perhaps the NSA will be nice and claim really convincingly that they can't access records from traffic lights... but that bird has flown, anyway.

jakecopp 9y ago

Even OpenCV running on a Raspberry Pi can pick out cars in a moving image - a bad offline solution (with a sensible fallback) would be better than a timer. On a large remote setup I think you are right though.

jakobegger 9y ago
OpenCV on a Raspberry does not sound like something that is reliable and easy to deploy. It‘s a long way to go from something that you hack together in the living room to something you can deploy on hundreds of traffic lights, that works in every weather, that can easily be configured for different use cases, and that can be serviced by the technicians.
- jakecopp 9y ago
  You are right. I'm trying to say I think the problem is development bound and not insurmountable (secure, reliable, good fallback to timer) rather than "moving, storing, and processing data" bound as per the parent comment.
  - tedmiston 9y ago
    I agree with you that developing a prototype wouldn't be too hard. But actually rolling it out within a few cities (and getting cities to pay for it) are where I think the complexities lie. I think it's a social or bureaucratic problem more than a technical one.
- halbritt 9y ago
  It can be: https://resin.io https://resin.io A Raspberry Pi is a surprisingly useful and cost effective device when it comes to IOT. Most industrially hardened devices of similar capacity cost a bit north of an order of magnitude more. There are really only a couple of things that would need to be addressed, a good weather-tight case that allowed for heat dissipation, decent storage (most microSD has a short lifespan), and a good 5v power supply. In many cases, designing a system that is cheap, expendable, and expected to fail is way less costly than the alternative.
  - TFortunato 9y ago
    Sone of what your saying is kind of making the point of the parent though. Yes, you can make the software deployment go easier, and resin looks like an interesting project from that front. But that really is only a small part of the problen, and those hardware problems you described aren't trivial. The testing you described to convincingly show that your device can handle the environmental requirements isn't trivial. (And by environmental, I dont just mean weather, but also things like available power quality, vibration, etc.) These industrial devices aren't expensive just because the suppliers aren't aware of RasPi, or are looking to gouge you. Its because they put in a lot of work to qualify these devices for their intended conditions. The RasPi, hacked up solution might actually be the WAY more expensive option over it's lifetime, if I have to roll maintenance crews every couple of months to replace SD cards or fix a flaky connector. And god forbid our code hangs in a way that makes all of the lights at an intersection green. "Oh you have a way to prevent that? Prove it." Designed to fail works fine for microservices where I can spin up a new instance rapidly, but it isn't the best match for industrial or infrastructure in most cases. Apologies if I'm coming across overly snarky here. I genuinely love the RaspPi, and its got a great niche for prototyping, hacking up one-off projects, or even as the base for many types of connected projects. But I've also worked on industrial and infrastructure types of systems, and more than once I've seen someone say that they've got a cheaper solution to X, when really they've got something that may look cheaper if your only looking at upfront costs, but they are completely ignoring the lifetime costs of the solution.
    - halbritt 9y ago

maxander 9y ago

A traffic light would only need to solve a much simpler problem than an autonomous car- after image-recognition, given the number of cars waiting/approaching at each direction, decide which lane(s) to give a green light to. Finding a reasonably optimal policy could be hard, yes, but once one is found that could be applied to all (or most) traffic lights, and it couldn't plausibly be more computationally intensive to run than the image-recognition step. Meanwhile, if conversation involves a plausible future where all/most vehicles (inevitably including police cars and other government-owned vehicles) are autonomous and have the same kind of sensors, its hard to imagine the anti-surveillance angle being a decisive factor. I'm not for pervasive surveillance, and perhaps the NSA will be nice and claim really convincingly that they can't access records from traffic lights... but that bird has flown, anyway.