| Main > Lightguns |
| GUN4IR - The Ultimate 4 Points Lightgun System |
| << < (205/227) > >> |
| Zebidee:
Thanks for that LED breakdown Jaybee :D --- Quote from: JayBee on October 13, 2022, 03:58:49 pm ---To give a small exemple, the leds we are currently using/recommending ideally need 80mA, at around 1.5v. That's only 37mW per resistor when they are by 3 in series, but 261mW if you use them one by one. --- End quote --- Those LEDs sure use a lot of power, makes sense to run in series and keep the watts/waste heat down. If there is an issue with current supply to a long string of LEDs, in series or parallel, spaced bypass capacitors (suggest/guess ceramic, maybe 103 [0.01uF] to 105 [1uF]) can help to smooth out power droops for those further down the line. |
| RandyT:
--- Quote from: JayBee on October 14, 2022, 10:28:36 am ---LEDs that fry usually stops conducting current properly. The power not used anymore by the led doesn't need to go somewhere, it's just not used. --- End quote --- With regard to the failing ones which sever or heat up, I agree. But those failure modes which leak current past definitely send that extra to the remaining LEDs. --- Quote ---If I wanted a sluggish and unreliable light gun system I would have stayed with a wiimote+software solution :dunno --- End quote --- What would lead you to that conclusion? Is it simply the lack of a good driver or have you concluded that there is something inherently bad/slow about the processor in the Wii remotes? From what I have been able to gather, all of the important sensor information is available from the Wii controller and would therefore be accessible by code running on a much faster and more powerful processor. Namely, the one in the PC. --- Quote ---(that black plastic in front of the sensor on the wiimote isn't just for show) --- End quote --- Heh. Actually, it might be. If the camera has an integrated filter, which I assume it does, then the plastic in front is just a window the camera can see through but you can't, in order to hide the inner components. I.e. just for show :). However, if the window is further filtering what gets in beyond the integrated filter, then that's a different story. What does your testing show? I'll buy that they didn't want the LEDs in the "sensor bar" to be seen, but oh the cost. What might be an interesting experiment to improve detection would be to remove any internal filter (assuming it's possible and also that it indeed has one tuned for 940nm) and replace it with an external one which is meant for 850nm and use those LEDs. Spectral response on virtually every silicon-based camera, even on the expensive ones intended for IR, drops by about 50% between 850 and 940nm, and I'm honestly very skeptical that these are much different, especially given the price. --- Quote ---That or the fact light blobs have a limited size in the sensor memory banks and becomes garbage passed that size. There are also several other issues like internal or external reflections and such ;) --- End quote --- It's possible. But it's probably not necessary to store bitmapped image data, outside of the standard frame-buffer, to get good blob co-ordinates. I.e. I would think the memory requirement for the calculations would remain constant, regardless of blob size. But once the sensor is driven to the point that there are no real borders to be found (everything above the low-level cutoff) then I'm sure it will have a bad time. |
| JayBee:
--- Quote from: RandyT on October 14, 2022, 03:20:06 pm ---But those failure modes which leak current past definitely send that extra to the remaining LEDs. --- End quote --- I totally understand your point there, but that's and extremely rare and unlikely case, and isn't really relevant in our case on LEDs in series vs in parallel. Let me ask you, if it was so much of an issues, why would all the engineers on the planet use IR LEDs in series in their IR point designs? --- Quote ---What would lead you to that conclusion? Is it simply the lack of a good driver or have you concluded that there is something inherently bad/slow about the processor in the Wii remotes? From what I have been able to gather, all of the important sensor information is available from the Wii controller and would therefore be accessible by code running on a much faster and more powerful processor. Namely, the one in the PC. --- End quote --- The extra processing happening in the wiimote itself, the way it's handled, and the BT protocol are the bottleneck here, and the sensor wasn't used to its maximum specs simply because it wouldn't have been useful. That means with a wiimote you'll never ever reach the 4ms latency I achieve with my gun system, especially without the Wii proprietary low latency BT protocol (which can't really be used for anything else than the Wii itself or Wii emulation). Sadly no good drivers can fix that. If it could I don't think I would have bothered making a full hardware solution. You might think latency isn't an issue, but lightguns are way more sensitive than normal controllers to latency if you are playing without crosshair (as it should always be). You want the hit to always land on time and exactly where you are aiming, not where you were aiming 2 or more frames ago. --- Quote ---Heh. Actually, it might be. If the camera has an integrated filter, which I assume it does, then the plastic in front is just a window the camera can see through but you can't, in order to hide the inner components. I.e. just for show :). However, if the window is further filtering what gets in beyond the integrated filter, then that's a different story. What does your testing show? I'll buy that they didn't want the LEDs in the "sensor bar" to be seen, but oh the cost. What might be an interesting experiment to improve detection would be to remove any internal filter (assuming it's possible and also that it indeed has one tuned for 940nm) and replace it with an external one which is meant for 850nm and use those LEDs. Spectral response on virtually every silicon-based camera, even on the expensive ones intended for IR, drops by about 50% between 850 and 940nm, and I'm honestly very skeptical that these are much different, especially given the price. --- End quote --- Not "might". The front plastic is an IR pass filter as the camera doesn't have a proper integrated filter, it relies on the extra IR pas filter, the same way it relies on external oscillator to drive it (later models don't need that extra hardware or extra filter). Please just try it by yourself before making assumptions, you'll see how bad the cam behaves without the front filter, no matter the type of led used or the cam sensitivity setting. It can catch some LEDs that aren't in the IR spectrum, and will catch tons of noises and reflections that cannot be filtered by software or cam settings. That's just the way it was designed. Having an IR pass filter that also hides the internal was most likely more cost effective than having to add a proper filter in the cam itself. The cost? I am not sure I'm following you here, how would that have been more expensive or less efficient (for that particular use) to use simple 940nm than using 850nm ones? The "sensor bar" (even if it's a weird name for a thing that doesn't have sensors) doesn't need expensive IR pass filter or anything, and uses very very basic low power LEDs (in series). I already tried what you are suggesting, and the results weren't good enough to be worth the switch to 850nm. And the whole point of using black LEDs is making them very discreet, using a wavelength we can see with naked eyes would make it completely counter productive. Again, I have no idea why you think I am guesstimating here. I have the feeling you think I don't know what I'm talking about here haha. You think you'd get more knowledge from quick online search than me in years of study on the subject? :lol --- Quote ---It's possible. But it's probably not necessary to store bitmapped image data, outside of the standard frame-buffer, to get good blob co-ordinates. I.e. I would think the memory requirement for the calculations would remain constant, regardless of blob size. But once the sensor is driven to the point that there are no real borders to be found (everything above the low-level cutoff) then I'm sure it will have a bad time. --- End quote --- It does store its data in fixed registers, that have a very limited size. Of course the computation of the blobs has its own limit, but the way the data is stored/prepared is also limiting it (newer more powerful sensors have far less limits on that aspect). And like I said, there are many other factors at play here but I won't go into detail, here is not the place to do. |
| hongliulin88@.com:
I have made a donation, can you give me a license? |
| RandyT:
--- Quote from: JayBee on October 15, 2022, 01:22:15 am ---I totally understand your point there, but that's and extremely rare and unlikely case, and isn't really relevant in our case on LEDs in series vs in parallel. --- End quote --- I feel like we are beating a dead horse here and I'm not getting through. LEDs in series is exactly the relevant case where current leakage failure modes are concerned. Parallel always isolates each LED, end of story. But the benefits of using them in series far outweighs any concerns about keeping a couple of cheap LEDs alive for longer in specific cases of failure, unless one has a visceral fear of soldering. So we agree fully on that. --- Quote ---The extra processing happening in the wiimote itself, the way it's handled, and the BT protocol are the bottleneck here, and the sensor wasn't used to its maximum specs simply because it wouldn't have been useful. That means with a wiimote you'll never ever reach the 4ms latency I achieve with my gun system, especially without the Wii proprietary low latency BT protocol (which can't really be used for anything else than the Wii itself or Wii emulation). Sadly no good drivers can fix that. If it could I don't think I would have bothered making a full hardware solution. --- End quote --- I don't see any of the bottlenecking you are describing in the examples being shown, and this is using a standard Wii remote. This tells me that any issues are the result of poor BT adapters and/or software implementations. And while this is purely academic, as your approach is plenty fast enough for a light gun, every reference to the camera module indicates that it provides x and y co-ordinates only once every 10ms, after which the processing of that data would take place. So, I'm assuming that actual latency of your system is at least 14ms, not the 4ms being stated. References for MoCap software using the stock remote is able to track objects in 3D with a 49ms latency, which also isn't bad, as moving from target to target can easily take 200ms. So, while yours is indeed very fast, far more "plug and play" and system compatible, I'm not willing to accept that it can't be done "well enough" on a PC with a stock remote, decent BT adapter and software. But for its lower speed, it would also be wireless :) Given the age of the device, however, It's doubtful anyone will bother to make something as polished as you have in that regard. --- Quote ---Not "might". The front plastic is an IR pass filter as the camera doesn't have a proper integrated filter, it relies on the extra IR pas filter. ... The cost? I am not sure I'm following you here, how would that have been more expensive or less efficient (for that particular use) to use simple 940nm than using 850nm ones? --- End quote --- Ok, thank you for that clarification on the camera. That actually answers the question I had a few posts back about its nature. So, it's not a specifically filtered camera module, rather relying on an external filter entirely. This means that anyone homebrewing from a Wii remote will need to come up with their own filter, or fashion the existing one into their design, and will need to be careful about light leakage into that area. The RobotShop module definitely sounds more appealing. It's unfortunate the supply is so intermittent. I didn't mean monetary cost, rather the cost of a ~%50 loss in sensitivity to avoid some faintly glowing red dots while playing :). I appreciate the responses to my questions. They helped to save my pristine remotes from the wrath of my screwdriver. |
| Navigation |
| Message Index |
| Next page |
| Previous page |