typically on these cameras the lens is mounted and focused by a screw thread. there is not usually an 'infinity stop' because the mount is very simple, so i would expect the lens may be mechanically positioned outside the useful focus range. a 110 degree FoV is a very wide lens, so the useful screw range may be quite mechanically narrow, but when positioned properly it will have a very deep in-focus field, capturing near objects and far objects clearly.
the datasheet doesn't say much about focus, but it looks like the rim of the lens is knurled for grip, so try rotating the lens. 'screw out' will bring focus nearer, 'screw in' will push focus farther. i would suggest indexing your start position with a paint pen for easy return, and then index the correct position if you find it.
if all else fails, you could place a small aperture in front of the lens. this will reduce light transmission but also improve the focus field, like squinting your eyes.
cristoperb 16 hours ago [-]
That's inexpensive enough to be the basis for a modern recreation of the CueCat:
Sadly, Useful Sensors seems to have pivoted to other edge AI tech and no longer sells this or their person detector.
haarts 13 hours ago [-]
Yeah, that is a shame. Couldn't find something similar unfortunately.
mananaysiempre 14 hours ago [-]
Somewhat incidentally, is there an actual description of how a low-tech QR code reader would work? I’ve looked for this a few years ago and all solutions I could find were of two flavours: (1) use ZXing (“Zebra Crossing”, a now-unmaintained library[1] for every 1D and 2D barcode under the sun); (2) use OpenCV. Nowhere could I find any discussion of how one would actually deal with the image-processing part by hand. And yet QR codes are 1994 tech, so they should hardly require fancy computer-vision stuff to process.
You can roughly divide barcode reading into a "frontend" and a "backend". The backend is the most well understood (but not necessarily trivial) part: you take a binary image, with each pixel corresponding to one little square in the QR code, and decode its payload. It doesn't need computer vision. The "frontend" is the part that takes the raw image containing the barcode and tries to find the barcode, and convert the barcode it finds into a nice, clean binary image for the backend. This is a computer vision problem and you can arbitrarily fancy, including up to using the latest trends in ML vision models. However, this isn't necessarily needed in most cases; after all, barcodes are designed to be easy to read for machines. With a large, sufficiently well focused and well exposed image of a barcode you can get away with simple classical computer vision algorithms like histogram-based binarization and some heuristics to identify the spatial extent of the barcode (for example, most barcode symbologies mandate "quiet space" (blank space) to be around the barcode, and have start and stop markers; QR codes have those prominent concentric squares on the corners).
As for implementation, Zxing-cpp [1] is still maintained, and pretty good as far as open source options go. At this point I'm not sure how related it is to the original zxing, as it has gone substantial development. It has python bindings which may be easier to use.
On mobile, Google MLkit and Apple vision also have barcode reading APIs, not open source but otherwise "free" as in beer.
I think many places roll their own. QR codes have a finder pattern of alternating black and white with relative spacing of 1-1-3-1-1 for any line that goes through the center of it. This has a low false positive rate so this step is the most important for performance. Since orientation doesn’t change the pattern horizontal scans are sufficient, once the center, scale, and rotation has been found the rest is fairly straight forward. There isn’t really a good reason why this set up couldn’t be rotation invariant, the processing power required is pretty low.
alex_suzuki 14 hours ago [-]
You could have a look at the ISO spec on QR Codes to get the authoritative source on what kind of processing required.
Alternatively (and what I would recommend), is grab a library that is dedicated to QR Code reading (I‘ve used Quirc, for example) and just read the code.
Typically you threshold an image to get a binary representation (1: black, 0: white). Then you detect the finder patterns by looking for 1-1-3-1-1 runs of black/white. Once you have a bunch of finder patterns localized, you form triplets and decode the binary matrix that they span.
And then there are a number of OSS implementations for Android (check fdroid.orgl, Debian/Ubuntu, etc. Maybe study the code?
mananaysiempre 12 hours ago [-]
That’s not what I’m asking about: once you’ve found the QR code in the bag of pixels you got from your camera and converted it to a boolean array of module colours, then yes, all you have left is a bit error-correction math and some amusingly archaic Japanese character encoding schemes—definitely some work, but ultimately just some work. (For that matter, the Wikipedia article on QR codes contains enough detail to do this.)
What has thus far remained a mystery to me is going from a bag of noisy pixels with a blurry photo of a tattoo on a hairy arm surrounded by random desk clutter to array of booleans. I meant “by hand” as in “without libraries”, not “using a human”, as in the latter case the human’s visual cortex does the interesting part! And the open-source Android apps that I’ve looked at just wrap ZXing, which is huge (so a sibling commenter’s suggestion of looking at a different, QR-code-specific library is helpful).
dimatura 5 hours ago [-]
You can examine the code of zxing-cpp (which is fairly nice IMO) for a simple, "classical computer vision" approach to this. It's not the most robust implementation but it is pretty functional.
But in general, you can divide the problem more or less like this (not necessarily in this order)
1. find the rough spatial region of the barcode. Crop that out and only focus on this
2. Correct ("rectify") for any rotation or perspective skew of the barcode, turn it into a frontoparallel version of the barcode
3. Binarize the image from RGB or grayscale into pure black and white
4. Normalize the size so that each pixel is the smallest spatial unit of the barcode.
jcynix 12 hours ago [-]
> What has thus far remained a mystery to me is going from a bag of noisy pixels [...] to array of booleans.
Ah, OK. You can use software like ImageMagick to partition images into levels of gray or just black and white. I have some examples somewhere I played with some time ago, but not accessible online right now, sorry. If the contrast of the original image is high enough, just the qrcode would remain to be parsed.
jcynix 11 hours ago [-]
Here's an example to start with: ImageMagick's -threshold or -adaptive-threshold (depending on the image's lighting) are what you want to look at, e.g. try something like
And if you wanna go even lower, you'll "raw" read the image pixel by pixel to normalise colour to black/white and then read that matrix for the QR pattern.
And then, cause there are some inverted colour QRs, flip and scan again.
Just checked and the cost for a (non aliexpress) seller ESP32-CAM dev board is around £5-£6 or less than £1 from aliexpress
waitwhat 14 hours ago [-]
Aliexpress listings can have multiple different items, and the price displayed in the search results will be that of the first of those (in your case, probably just an antenna) rather than the actual item you searched for or even the item image shown on the results page.
Neywiny 7 hours ago [-]
Not just the first, seems like the cheapest. I did a quick search and one result listed the second object's price, which was some permanent adapter board. But it's hard to fix such a thing. For example what if you really did want to buy another antenna for the device? Ok so maybe you require the listed price be the maximum. But what about like a raspberry pi kit where maybe you don't want the case or high capacity sd card or RAM, which could bring down the cost dramatically.
pseudosavant 14 hours ago [-]
I even found them on Amazon with Prime shipping for ~$8/each. Curious how challenging parsing a QR code would be with that?
xmprt 15 hours ago [-]
My experience with small QR code readers like this on ESP32 boards is that without a viewfinder, they lose a lot of utility. The feedback loop that a viewfinder gives with positioning and knowing when the QR code is detected is invaluable.
baby_souffle 15 hours ago [-]
All of the cheap camera based two-dimensional barcode modules that I see on AliExpress tend to ship with a white LED as well as a red LED. The white LED is for general flood illumination and the red LED has some sort of pattern and lens array that keeps it centered in the cameras field of view and appears sharp and focused when the barcode is at the optimal distance.
Camera detects motion, turns white LED and red LED on. Paper or screen with the QR code is now illuminated and humans can move up and down until the red Target appears in the center and in focus. Approximately a quarter of a second after that happens, you hear the beep noise indicating a successful read and decode
Liftyee 15 hours ago [-]
In places where QR payment is commonplace, readers without viewfinders often get round this issue with a pyramidal frame in front of the camera marking out its FOV, the rectangular opening indicating where the QR code should be aligned. From experience, the code often reads before you even finish approaching the reader.
nemomarx 15 hours ago [-]
I wonder if you could project some red LEDs instead, like barcode scanners?
therein 15 hours ago [-]
You can, and it still results in a subpar experience. There are products out there that do exactly that.
benjaminbenben 15 hours ago [-]
If you pair this with a eink display you could send messages back and forth with another device https://remotehack.space/QR-TX/
degamad 6 hours ago [-]
Great for bridging air-gaps....
harrylepotter 12 hours ago [-]
A fridge-mounted ESP32 barcode integration would be pretty awesome for tracking fridge inventory
unquietwiki 13 hours ago [-]
I've had a recurring idea in my head of a sensor you could mount in your car, and then be able to read QR codes from the side of the road, and get an index of all the businesses you'd be driving by for later lookup. Not sure how feasible or useful it'd actually be...
avidiax 13 hours ago [-]
That seems easier to do by using OpenStreetMaps and a GPS trace. You would need the businesses to cooperate by putting a QR code out, so they might as well cooperate and keep a maps listing up to date.
I could imagine maybe OCRing the results from a line-scan camera. That would read all the business signs and street names as you drive by them.
Too 2 hours ago [-]
”Attractions along the route” must have been a standard feature on satnavs since the very first standalone TomTom sucked onto your windscreen. Newer cars having Google Maps built in make this even richer.
jcynix 12 hours ago [-]
Why would I want to have this? No idea, but if I did I probably would use a modern dashcam (these can easily do 4K HDR with 60 fps nowadays) and later analyze the recording with OpenVC.
Some viofo dashcams even allow the connection of two secondary cams (those only FullHD) so you could scan to the left and right simultaneously to the front.
alnwlsn 12 hours ago [-]
Reminds me of one of the ideas I heard about for how to do road navigation before GPS - you paint a bunch of barcodes on the road that your car reads as you drive over them, and then your computer figures out where you are (you would probably use dead reckoning with your car's speed and time, too).
ktallett 13 hours ago [-]
Would you genuinely want this? I personally can't see why. Perhaps at conventions it could be useful as it's hard to visit every table.
jrexilius 6 hours ago [-]
I love these. Kinda insane they got it packaged so cheaply.
amelius 14 hours ago [-]
Anyone who knows of a cheap sensor that works in Linux and can read Digikey bag barcodes?
MiguelHudnandez 11 hours ago [-]
I'm unclear about a specific sensor, but it looks like the format you want to decode would be "Data Matrix ECC 200"
typically on these cameras the lens is mounted and focused by a screw thread. there is not usually an 'infinity stop' because the mount is very simple, so i would expect the lens may be mechanically positioned outside the useful focus range. a 110 degree FoV is a very wide lens, so the useful screw range may be quite mechanically narrow, but when positioned properly it will have a very deep in-focus field, capturing near objects and far objects clearly.
the datasheet doesn't say much about focus, but it looks like the rim of the lens is knurled for grip, so try rotating the lens. 'screw out' will bring focus nearer, 'screw in' will push focus farther. i would suggest indexing your start position with a paint pen for easy return, and then index the correct position if you find it.
if all else fails, you could place a small aperture in front of the lens. this will reduce light transmission but also improve the focus field, like squinting your eyes.
https://en.wikipedia.org/wiki/CueCat
[1] https://github.com/zxing/zxing
As for implementation, Zxing-cpp [1] is still maintained, and pretty good as far as open source options go. At this point I'm not sure how related it is to the original zxing, as it has gone substantial development. It has python bindings which may be easier to use.
On mobile, Google MLkit and Apple vision also have barcode reading APIs, not open source but otherwise "free" as in beer.
[1] https://github.com/zxing-cpp/zxing-cpp
Alternatively (and what I would recommend), is grab a library that is dedicated to QR Code reading (I‘ve used Quirc, for example) and just read the code.
Typically you threshold an image to get a binary representation (1: black, 0: white). Then you detect the finder patterns by looking for 1-1-3-1-1 runs of black/white. Once you have a bunch of finder patterns localized, you form triplets and decode the binary matrix that they span.
http://blog.qartis.com/decoding-small-qr-codes-by-hand/
https://beck-thompson.github.io/QRcodewebsite/
Reading QR codes without a computer! https://qr.blinry.org/
And then there are a number of OSS implementations for Android (check fdroid.orgl, Debian/Ubuntu, etc. Maybe study the code?
What has thus far remained a mystery to me is going from a bag of noisy pixels with a blurry photo of a tattoo on a hairy arm surrounded by random desk clutter to array of booleans. I meant “by hand” as in “without libraries”, not “using a human”, as in the latter case the human’s visual cortex does the interesting part! And the open-source Android apps that I’ve looked at just wrap ZXing, which is huge (so a sibling commenter’s suggestion of looking at a different, QR-code-specific library is helpful).
But in general, you can divide the problem more or less like this (not necessarily in this order) 1. find the rough spatial region of the barcode. Crop that out and only focus on this 2. Correct ("rectify") for any rotation or perspective skew of the barcode, turn it into a frontoparallel version of the barcode 3. Binarize the image from RGB or grayscale into pure black and white 4. Normalize the size so that each pixel is the smallest spatial unit of the barcode.
Ah, OK. You can use software like ImageMagick to partition images into levels of gray or just black and white. I have some examples somewhere I played with some time ago, but not accessible online right now, sorry. If the contrast of the original image is high enough, just the qrcode would remain to be parsed.
And then, cause there are some inverted colour QRs, flip and scan again.
Camera detects motion, turns white LED and red LED on. Paper or screen with the QR code is now illuminated and humans can move up and down until the red Target appears in the center and in focus. Approximately a quarter of a second after that happens, you hear the beep noise indicating a successful read and decode
I could imagine maybe OCRing the results from a line-scan camera. That would read all the business signs and street names as you drive by them.
Some viofo dashcams even allow the connection of two secondary cams (those only FullHD) so you could scan to the left and right simultaneously to the front.
https://forum.digikey.com/t/digikey-product-labels-decoding-...
I think a smartphone and custom app would be the worst case scenario in terms of cost, and that could be pretty cheap.