At Yoctopuce, we take a picture of each package before we entrust it to the postal services, in case it gets lost during shipment. Up to now, we did this manually by chucking the package on a simple desktop scanner and we saved the file somewhere. But we got tired on this repetitive and completely uninteresting task. So we decided to automate the process...
Anatomy of a Yoctopuce package
If you ever ordered something from Yoctopuce, you may have noticed that Yoctopuce packages are covered with stickers. Far from being decorative, these stickers have each their own role.
A typical Yoctopuce package
There are usually 5 stickers:
- One for the address and the shipment number, the latest as a code bar and text.
- One for the tracking number, as a code bar and text as well.
- A CN22 form to declare the package content to the customs.
- One for the postage stamp with a datamatrix code describing the postage amount.
- A last one to indicate that it's a priority package, but frankly, we suspect this one to be mostly decorative, given its lack of efficiency in some countries.
Some destinations require a slightly different configuration, but the principle stays unchanged.
We'd like to take a picture of each package right after postage and save the image in order to be able to quickly retrieve it. And while we are at it, we'd like to store the package weight as well as the postage amount too. Postage is done at Yoctopuce premises, with the help of a dedicated device including a scale but on which we have no control. And, most likely, the Swiss postal services would hate that we tinker with it. The idea is therefore to build an independent system which allows us to:
- Weigh the package,
- Take a picture of it,
- Scan the shipment number and postage amount bar codes,
- Save the results in our database.
There are industrial scanners which could do all that in a jiffy, but we prefer to build our own system, just for the fun of it.
After a few tests with a webcam which were not satisfying at all, we decided to think big with more serious hardware. We selected a Canon EOS 700D mounted on a copy stand. This device is linked by USB to a computer and controlled by the Canon SDK. It is powered by a suitable AC adapter.
We mounted a camera on the copy stand
To weigh the packages, we used a scale with an RS232 output. We already described this system in a previous post.
Finally, to light the scene, we used a led torch. Good lighting is required for the camera to focus correctly. To fix the torch to the copy stand, we used the end of a selfie perch which we cut and then glued to a kind of plastic pincer made with the 3D printer. This pincer is then mounted on the copy stand.
To interface everything, we naturally used Yoctopuce modules. A Yocto-RS232 to interface the scale, a Yocto-PowerRelay to switch the torch on and off. We configured the camera to go into sleeping mode if it hasn't been used in a few minutes, and we use a Yocto-Relay to switch it back on. Indeed, we only need to close the electric contact corresponding to the focus on the remote control connector for the camera to wake up.
The installation diagram
Writing the software controlling the installation wasn't a very complex task: it essentially consisted in putting together several libraries. To drive the camera and to retrieve the pictures directly by USB, we used the Canon library with a C# wrapper written by Johannes Bildstein. To recognize the bar codes, we used the SD-toolkit commercial library. And naturally, to drive the Yoctopuce modules, we used our API. We wrote the software in such a way that as soon as a package is put on the scale, the system wakes up, takes a picture, and scans the bar codes. A Yocto-Buzzer signals the end of the process.
Pitfalls and issues
The prototype was developed with an EOS 70D. However, we went into production with a 700D, which is much cheaper. This allowed us to notice that the autofocus system of a 700D is much less efficient than that of the 70D. It's particularly evident with the liveview mode on. So much so that we even had to renounce using this mode which allowed us to see in real time on the screen what the camera was taking.
The Canon SDK is wholly based on callbacks: you ask the camera to take a picture, and you wait for the SDK to call one of your functions with the content of the picture. Except that, once in a while, your callback is never called, without you knowing why: no exception, no error code. In this case, closing and reopening the session with the camera solves the issue.
The SD-toolkit library is reasonably efficient, but it sometimes has trouble reading the low contrast datamatrix code for postage. We solved the issue by scanning only some zones of the picture, where we know that the codes are most likely found. Bonus: as we scan only part of the picture, the process is much faster.
The whole system
We succeeded in building an efficient bar code reader for a relatively cheap cost compared to a professional dedicated system. In the opposite to many of our Friday projects, this one isn't centered on Yoctopuce products. Here, our modules only serve to easily interface the distinct components of a more complex system. This probably corresponds rather well to the use that customers make of our products.