The real fun: Hardware

Alright, enough about the software for a minute since there's a lot of stuff I tested and experimented with on the hardware side and I may not be able to keep all of the timeline flowing exactly as it happened, but I'll do my best to keep it chronological.

This is still pretty early, around 2022 when I was trying to play with ideas on how I can have a physical storage device actually determine quantities. Weight seemed to be something generic, to play into the "industry agnostic" ideals I was working towards. Over the years a lot of people have inquired about "why don't you use machine vision?" to which I point them towards the ol' jar of jelly beans problem. Trying to figure out how many things are in a 3D space that can constantly move around seems extremely complex, not to mention expensive, if there's going to be a lot of bins for small loose parts.

At this time I wasn't focusing as much on workbench sized storage, but was just trying to figure out something.

Cheap Weight sensing

Sensors are almost never cheap, but I came across this marco reps video about using Velostat as a pressure sensor.

This seemed rather intriguing; a paper thin sensor that can change resistance based off of pressure? Awesome!

The not so awesome part was finding out the hard way that not only is everything an antenna, but everything is a temperature sensor. I was working on the analog frontends for mass spectrometers at my day job, and was struggling with temperature compensation so I was well familiar with the subject but not for how far reaching it went.

As any good macro reps enjoyer, I couldn't help but try to measure the drift of the velostat resistance over time. Without a GPIB setup for my Keithly 2001, I took a timelapse video of the Velostat hooked up to kelvin probes.

Though the more damning issue to showcase the temperature issue was blowing in the direction of the velostat from about 10ft/3m away. I was in the door frame of the room, and saw that the number started climbing. Not exactly something I wanted to bother with. I really wanted to make sure everything was as good as I could possibly make it, and this felt like it was not stable enough to keep track of things.

This of course was after designing some of the mechanical/electrical setup so I needed to revisit exactly what I wanted to do there.

I may revisit the Velostat at some point, but doesn't seem like the best use of time at the moment.

Drawer Concept

I thought to make something straightforward of copying something like a cabinet storage unit for parts would be something useful to start with, but didn't want to reinvent the wheel. I thought it could be interesting to have a 19" rack mounted storage drawer, so I started work on exactly that which is shown below.

Using some E-Ink displays in the front, the 6 bins with Velostat sheets on top, resulted in a rather hefty size for about $150 in raw sheet metal parts for quantities of 1k. Seemed like a reasonable thing, but I never ended up getting it fabricated.

I did get the circuit boards made to try and get something together, but not much was done with them either. Some of the concepts stuck around from that for the later designs

Architecture

I wanted to have an extensible system to communicate with each sensor bin, without needing to design new electronics for every configuration of sensors. Especially, I didn't want to be tied to only ever using weight based sensors. 

I would have loved to keep the E-ink displays on each bin, to provide a really simple static way to showcase exactly what part is in a bin and any additional info in them, but that became costly fast. In this concept, I tried to have columns tied to a specific display, which could work again in the future but with individual bins it is a bit more difficult.

Due to development in the middle of the COVID chip shortages, I found that the ATSAMD family was still in plentiful stock, and settled on a ATSAMDA1 to use. This was for the communication between all of the different sensors, as I needed as many SERCOM ports as possible.

Sensor Communication

To actually communicate between the bins and some host, I had been thinking of a few different options: CAN, RS485, and I2C.

CAN seemed like a reasonable option, but it would require additional costs with a microcontroller for every sensor bin. RS485 was pretty much the same, but there were cheaper interfaces to generate the differential pairs. This however still requires a microcontroller, which for this design I put inside the connector segments. This way, it's possible to duplicate all of the bins, and then have knowledge of where things are. I did not keep this architecture for the newer designs, since this is still complicated for moving a bin around. How can you ensure that a bin is what it says it is without knowing anything about it? Each bin would require their own microcontroller, which is the one thing I was trying to avoid for cost reasons. 

In an attempt to resolve that, I added on I2C EEPROMs with 128 bit serial numbers that are programmed at the factory to be unique. This way, the data could be found on the server, without requiring anything to be stored on the device. Of course, external storage is always useful so even though I didn't have any plans for it that second, it is still useful to have.