Hey All, I’ve been looking at taking inventory of my teams parts and tools and cataloging it all. (I’m suprised it hasn’t been done already.) and I was just wondering what a good layout for a google spreadsheet would be and any tips you guys might have. Thanks for any help you can offer 
Typical inventory (not catalog) sheets specify:
Name of item
Part number of item
Quantity in stock
Location (where it is)
Source (where to get more)
In a commercial application, you also record the cost.
In a warehouse application, you also record the velocity and lead time.
(Velocity is how fast these ‘sell’, and lead time is how long it takes to get more)
You can get into a lot more detail, but that’ll get you started.
We often re-use components if a particular robot or robot system is not going to be kept. Then, when a motor or spike fails, we never seem to know how old it is. I’d like to implement a system that records the date the part was acquired - so we could start calculating mean time to failure statistics.
We usually just sharpie the date on it, or if we are feeling fancy, use the label maker. 
Whenever you get new components, label each one (with a good label maker, not just sharpie) with a unique serial number. Add that to the standard inventory list as Don described, and add a field for “purchase date” as well, and voila!
Calculating time-to-failure might be harder; components fail for many different reasons. It could die after hundreds of hours of use due to wear and tear, or it could die after a single day of use because of an overheat, short, physical damage, etc.
I’m no expert on statistical analysis, but I think you would need a pretty large dataset before you started seeing a trend. If I’m wrong, someone please correct me 
No…you’re absolutely right. For a true measure we would need a great deal of data, I’m more concerned with having a general idea if the component “should” have failed. If a spike is only a year old and fails we may investigate differently than if it is several years old and fails.
Thanks a lot guys, this info should help a lot in this process, and as for custom serial numbers, should I just use a label maker and start at one or do you recommend a specific system for that?
Ah, I see, that makes sense.
You can use your serial numbers to do a bit of organization too.
For instance, a particular digit in the number could signify something. Say you decide that you’ll use six-digit numbers for serials. The first number could designate what group it’s associated with.
So maybe a number like:
1xxxxx would be a shop tool
2xxxxx would be robot components
3xxxxx for electronics
4xxxxx for computers
And so on. And then you can even have sub-categories.
So a 11xxxx might be a shop hand tool, 12xxxx a power tool, 13xxxx for machine tooling (drill bits, endmills, lathe tools, saw blades, etc).
In the same way, under electronics you might have categories for motors, motor controllers, etc.
Though you probably want to leave the last two or three digits to be the actual item number, which would just start at 1 and go from there.
I’d actually suggest two systems. One should be used for parts, and one for tools.
For tools, the team number should be in the serial number (helps if it’s loaned out), as well as if it’s a tool to take to competition, and probably where it goes in the shop. As an example, 3617C020304 could be a tool belonging to team 3617, going to competition, stored in toolbox 2, drawer 3, and it’s the #4 tool out of that drawer. Size might also be a good thing to include, or not. The key thing is that any team member should be able to put it away almost without thinking, even if they’d never seen the tool out before.
For parts, that’s a bit tougher. Raw material probably shouldn’t have a part number–instead, sort by type and label the bins/racks as much as possible with size data. But if we’re dealing with COTS parts, or parts built for a particular robot, then having a year (purchase or robot year, depending on COTS/custom status) and then having general type of part (motor, gearbox, whatever) and a number is probably a good idea.
I have a feeling that it would be wise for me to start working on a RPi-based server for all this data, so everyone can access and modify it at the same time. Basically like a spreadsheet, but looks better, is more powerful and could also give alerts when the inventory of something is running out. I’ll have that as a long-term project and share it with other teams after I am done!