This is something of a combination lab journal and DIY/Maker blog. I’m a research and development engineer in my day job; my formal education is in mechanical engineering, but I’ve learned a bit of electrical and software engineering on the job. Working in R&D at a small company is a great way to be introduced to lots of new skills, but projects come and go – and when they go, suddenly my boss doesn’t want to keep paying me to read about control theory or low power sensor networks when my new project needs a magnetic circuit design.
I sold my soul to engineering when I was about 10, though, and I find it hard to stop at just an “introduction” to a new skill. I’ve been particularly taken with my dalliances into the areas of control theory, circuit design, and embedded software – which, combined with the enjoyment of system dynamics I had from my mechanical engineering training, leads nicely into an interest in automation and robotics.
Unfortunately, that’s not what we primarily do at my job, so I’m dipping my toe into the world of hobbyist automation and robotics.
There is a ton to learn out there, and while I may not be at square one I’m certainly not past square four. That’s where “reinventing the square wheel” comes in. The phrase “reinventing the wheel”, of course, refers to going to all the effort to recreate something which already exists; I want to listen to music wherever I go, so I go through the effort to design and build an iPod. “Reinventing the square wheel”, on the other hand, would be going through the effort to design and build a Walkman. Not only have I duplicated the effort to create something which already exists, but I’ve recreated something inferior to something else which already exists.
Clearly reinventing the wheel is bad and reinventing the square wheel is worse when one is being paid to design new products. But when trying to learn a new area of knowledge, it’s almost mandatory if one wants to truly understand. Sure, I could just teach myself how to build a copy of my Honda Fit, but I’m pretty sure I’d have a deeper, fuller understanding of automotive design if I taught myself to build a Model T Ford first – and I bet I’d have a much easier time building the Fit after I’d had the experience of building the Model T.
On the same note, I could dive directly into trying to build a modified Roomba with GPS and adaptive control algorithms and voice-recognition that will fetch me a specified type of beer from the fridge wherever I am in my house, but it would take forever and I would almost certainly fail utterly. As cool as that Roomba sounds, I think I’ll be better served starting with something simpler – like maybe writing a piece of code that will make a motor turn. I can get to the sensors later – though I probably won’t wait quite so long on the beer.
Nothing I post about will be revolutionary, or even new. I’m not trying to create something better than, or even remotely approaching, SpaceX or Boston Dynamics. Instead, this blog will be, at least at first, a rather ad-hoc collection of little unrelated bits of tinkering and playing around. I can nearly guarantee that someone else will have done everything I post about before me, that they’ll probably have done it better than I will, and that I’ll probably be using their own blog posts as a guide in my efforts to turn their wonderfully elegant circuit design into a mess of unnecessary wiring or to mistype a line of code in their drive code and send my robot straight down the stairs.
If you, the hypothetical reader, have any training in electronics, software writing, robotics, this blog may well turn out to be a series of facepalm moments as I burn out another transistor because I forgot a flyback diode or spend 5 hours swearing at my compiler because I left a bracket open. Hits, tips, and constructive criticism are encouraged!