↑ RobotDesigns

Page Created: 6/24/2014   Last Modified: 10/9/2020   Last Generated: 5/6/2024

My first robot culminated in RobotChess, but after I became disillusioned with academia, I didn't revisit robotics for another 25 years.

However, in the early 2010s, the maker movement, 3D printer and RaspberryPi renewed my interest. The 3D printer makes it practical to design and print gears, and the Raspberry Pi is a cheap, low-power, Linux computer. There is also a new industry in hobby robotics and inexpensive Internet-capable microcontrollers, and it is much easier to purchase parts and sensors than it was in the 1980s.

I've always wanted to build and run my own factory. I have all of the skills needed to build the systems that compose and run it, but time and energy is the hard part. So I thought, what if the product of the factory can actually be used to automate parts of it? My brain usually looks for these kinds of benefits and relationships. In effect, I am performing early optimization, a very dangerous thing that can get you into cycles of re-doing your work over and over but never producing anything to show for it. In computing, this is called premature optimization, a big no-no.

But, IF you have enough foresight and can think ahead, a little early optimization can be a good thing, in theory.

Because of my interest in the VendingMachine (which is really just another model of computation), I started designing one. My design goals were to keep it as simple to manufacture as possible, most of it on a 3D printer, keep the parts cost low, keep it small in size, and allow it to scale. These are critical to allowing one to produce small amounts and then gradually grow a business.

A vending machine is essentially an inventory management device. You have some inventory (a mini warehouse), and you need some automatic way of delivering the goods to the customer (based on their choice).

While I won't reveal any of my designs publicly since I still may try to produce them in the future, it was a fascinating journey that taught me things about the world that I didn't expect. If you haven't done so, try designing an electro-mechanical machine to do a task sometime--it will teach you interesting things about the world.

The VendingMachine is a kind of stage, and what I found out was that instead of building the entire stage, it was more efficient to just build the "actor" and let it perform, so to speak. In computing, this is called the Actor model↗.

Many of the devices you use every day are robots--a coffeemaker, an automobile, a freezer, but we just don't recognize them as such. They vary in their "smartness".

So you first decide what you want it to actually do in the real world, then think through algorithmically how a machine would accomplish the steps needed. The word "algorithm" like the word "computer" is actually very old, and you may hear the term used in old movies, before the computer era, but back then it was applied to people doing repetitive tasks, instead of machines.

But you have some constraints, such as the economic ones I mentioned above, along with physical constraints, such as what technologies are available to us and what physical laws need to be followed.

At first, I began designing monolithic robots, big, multi-function robots that performed the exact task needed. They would pick out the product and dump it out the chute to the customer. If you look at today's vending machines in the US, they use mechanisms to allow easy loading of their product and use simple motors and gravity to their benefit.

Gravity is like a spring; it can store energy relative to the height of an object above the surface of the earth (called potential energy). When a person loads a vending machine, performing mechanical work, they lift the product a few feet up and put it in place. In effect, they have imparted some of their own body's energy into the machine, so the machine now has to do less work to release it back to you. The same principle applies to machines such as grandfather clocks.

So a lot of vending machines are designed to take advantage of this and keep the mechanisms as simple as possible. But the machines themselves are fairly large. Some vending machines use a robotic picker to pull out the product and deliver it, but the robotic arm is fairly complex and requires more energy. And if the mechanism breaks down, you have a high repair bill. Japan has some pretty advanced machines that I have never seen in the US.

As I began to create and revise my designs, a surprising thing happened: Designs that perform poorly in one thing are great for another thing. There is no bad design. There is no perfect design. Every design has its place in nature. The key is to optimize it to your goals at hand, which I understood very well due to my previous experience in optimization.

So, just like when a programmer breaks downs a more complex program into modules, abstracting away commonly repeated patterns, I began to break down the machine into simpler machines, and what I found astounded me.

By breaking a robot into two robots and having those two robots cooperate, you can get better results with even less resources. One reason it has been so difficult for engineers to create the flying car is because the airplane and the automobile are each designed around different physical constraints. But what if you created a sort of in-between robot that could neither fly nor drive, but by creating more than one of them, their cooperation allowed them to fly and drive better than a single machine?

So my robot got a lot smaller, and, like transforming toys, it had the ability to change shape. And by putting two of them together in different states, the shapes fit in a way to achieve the goal.

This design had great benefits--the mechanism was simple, the parts count low. A replacement bot could replace either of the two bots.

Robots have been used in warehouses for a long time. The warehouse is an orderly environment, so it doesn't need a lot of computer vision or AI. Robots have been used to deliver parts around the factory for decades.

The reason you don't see them very often in your home or office yet is because it is not orderly, and the computer cannot easily compute the path to its goal (called pathfinding or motion planning). I use a Neato XV-21 vacuum-cleaning robot to clean the floor, but it has to use a Lidar↗ laser and an internal map to "see". I bypassed this problem in my designs by using "beaconing", putting beacons in the environment to let a robot know where it is at all times.

The robot doesn't have to self-contain its entire intelligence since artificial intelligence can arise simply through "context". A bot that can interact with its environment, a strictly defined context, can sometimes show emergent behavior.

If the robot got stuck or needed help, it could call out to humans in the vicinity or call out to other robots for assistance. If you have enough of these self-transforming bots on hand, it's like parallel threads in a multi-threaded OS; they will still get the job done.

It's not exactly swarm behavior, just like my OswaldCluster is not exactly a cluster, but it is effective.

My idea was also to make the bots "cute", using beeps and boops instead of human speech. I created a lot of systems that use speech, but we don't always need robots to emulate us. We appreciate, just like the animal kingdom, that they have different sounds and different personalities. And people are more likely to help cute bots when they get stuck and ask for help.

My interest in the RogueLike also translated well into robotics. A roguelike is full of mini "bots" that traverse a dungeon. And you have some of the same problems to overcome (pathfinding, keeping them from blocking each other, emergent intelligence from interacting with a "smart" environment, etc). So if you can program the roguelike, you can program real-world bots.

In the future, we will be surrounded by robots. As of the time of this writing, we are on the cusp of the robot era, just like the early days of the Internet. The Internet created a feedback loop that drove further growth of itself, and similarly, work done by robots will drive the further growth of robotics.

Also, as I began to research machines, I was surprised to find out that most of the innovations in machinery are at least 100 years old. Like any technology, it has its golden age, and the men of the industrial revolution did some amazing work↗. Since we are using newer technologies today, we are not investing as much time in older technologies as that generation did. I had learned a lot about gears, motors, and batteries from a hobby in radio-controlled electric cars when I was younger, and have repaired my own automobiles for decades, but my research into "simple machines" and multiple types of gears made me realize how important these technologies are.

I did a lot of research on electromagnets, but they exceeded the power constraints of my designs, so I spent weeks designing systems using rare-earth magnets. Rare-earth magnets are extremely powerful permanent magnets that have all sorts of uses in robotics; they can be used as locking devices, pickup devices, and they don't require any power. But the problem is that once they attract something it often requires a lot of power to release them. A latching solenoid is one such device.

I experimented with building my own latching solenoid until I came across the wonderful Halbach array↗. It is a permanent magnet that can be turned on and off like a switch. I never knew such a thing existed, as it was invented in the 1980s. Have you ever wondered why those flat refrigerator magnets stick on one side, but not the other, like a normal magnet would? It is actually a Halbach array. But if your array consists of cylinder magnets, it only takes a small amount of force to rotate the cylinders and reverse the poles. And if you curl this into a cylinder, you create a Halbach cylinder. Nested Halbach cylinders have very interesting properties, as well.

I also studied the inverted pendulum problem (the Segway effect), trying to come up with the simplest sensor arrangement possible. It is a difficult problem to solve, but once solved, it vastly simplifies the mechanisms needed for balance, steering, and docking. This was integral to my design.

Ultimately, however, I found that each part of the vending machine would have to be prototyped and tested in the real world. It's a solved problem, but logistically it would be too time-consuming for me to continue in my spare time. There are a lot of entrepreneurs that are gambling their future on small manufacturing start-ups in the United States. A lot of them have failed, but some have succeeded.

So I decided that this would have to be secondary to my primary business. I would have to first start a business in another area, then tool up for a different product line. In the meantime, I decided to build some robots to help me in my personal life, robots that didn't require the quality and rigor of a commercialized product, that just had to be "good enough" to tilt that balance from chaos to order...

In 2013, I created my second robot, OswaldBot, a talking, home automation robot controlled by a smartphone, which predated the later smarthome/IoT craze and proprietary smart speaker devices. It understands a simple domain-specific language, uses a rudimentary laser to see, and controls other things using old-fashioned transistors + relay switches. This was a crude attempt to finally get something into operation in the 21st century to make my life easier, and it has been running reliably for 11 years now. The software is neither elegant from a design nor engineering perspective, and isn't even event-driven. It simply loops endlessly, or spins↗, awaiting changes and responding to them, which is sometimes a bit too slow in interpreted Python, reminiscent of my old 8-bit BASIC days, allowing embarrassingly parallel↗ routines to deadlock the system. I keep meaning to someday redesign and program it "the right way", but I put up with its idiosyncrasies and applied the improvements to my next robot.

In 2016, I began building my third robot, an independently-powered, autonomous, amateur radio communication relay called TrillSat and borrowed a lot of ideas from OswaldBot but decided to instead use multithreading and multiprocessing parallel techniques and event-driven programming to allow multi-user communication and asynchronous text streams from multiple devices. I even ended up creating a new device driver and text server to overcome some of its hardware and and power limitations. I had to design numerous subsystems (environmental, redundant, fault tolerant) as it is intended to operate outside, exposed to the elements 24-hours a day, during all 4 seasons at my temperate latitude. I replaced many of those old electromechanical transistor/relay pairs with solid state, logic-level MOSFETs, amazing devices that weren't available when I was younger, but I did add one latching relay, as those relays still maintain the unique benefits of requiring zero power to maintain their state while minimizing their voltage drop across their contacts, unlike the MOSFETs. But the MOSFETs I used cost under $2 but can switch up to 60 amps, and can be pulse-modulated to switch over 200 amps. Wow.

I avoid stochastic system programming whenever possible in lieu of discrete, deterministic methods, but this latest project has pushed me right up against Nature, and I had to look it in the eye, and it is very fearsome.

Comments