Have you ever tired of playing with your latest robot invention and wished you could just eat it? Well, that’s exactly what a team of researchers is investigating. There is a fully funded research initiative (not an April Fools’ joke, as far as we know) delving into the possibilities of edible electronics and mechanical systems used in robotics. The team, led by EPFL in Switzerland, combines food process engineering, printed and molecular electronics, and soft robotics to create fully functional and practical robots that can be consumed at the end of their lifespan. While the concept of food-based robots may seem unusual, the potential applications in medicine and reducing waste during food delivery are significant driving factors behind this idea.

The Robofood project (some articles are paywalled!) has clearly made some inroads into the many components needed. Take, for example, batteries. Normally, ingesting a battery would result in a trip to the emergency room, but an edible battery can be made from an anode of riboflavin (found in almonds and egg whites) and a cathode of quercetin, as we covered a while ago. The team proposed another battery using activated charcoal (AC) electrodes on a gelatin substrate. Water is split into its constituent oxygen and hydrogen by applying a voltage to the structure. These gasses adsorb into the AC surface and later recombine back into the water, providing a usable one-volt output for ten minutes with a similar charge time. This simple structure is reusable and, once expired, dissolves harmlessly in (simulated) gastric fluid in twenty minutes. Such a device could potentially power a GI-tract exploratory robot or other sensor devices.

But what use is power without control? (as some car tyre advert once said) Microfluidic control circuits can be created using a stack of edible materials, primarily oleogels, like ethyl cellulose, mixed with an organic oil such as olive oil. A microfluidic NOT gate combines a pressure-controlled switch with a fluid resistor as the ‘pull-up’. The switch has a horizontal flow channel with a blockage that is cleared when a control pressure is applied. As every electronic engineer knows, once you have a controlled switch and a resistor, you can build NOT gates and all the other logic functions, flip-flops, and memories. Although they are very slow, the control components are importantly edible.

Edible electronics don’t feature here often, but we did dig up this simple edible chocolate bunny that screams when you bite it. Who wouldn’t want one of those?

[Benjie Holson] is an experienced roboticist and wrote an interesting article published on IEEE Spectrum about how the idea most people have of non-roboticists is a myth, and efforts to target this group with simplified robotic frameworks tend to be doomed.

Now, let’s make a couple things absolutely clear right up front: He is not saying robots shouldn’t be easier to program, nor is he saying that non-roboticists literally do not exist (of course they do.) The issues he’s highlighting really come down to product design.

[Benjie] points out that programming robots is super hard, but it’s also hard in more than one way and for more than one reason. And when people try to create a product to make it easier, they tend to commit two big product design no-no’s: they focus on the wrong hard parts, and they design their product for a vaguely-defined audience that doesn’t really exist. That group is the mythical non-roboticist.

These are actually very solid points to make in terms of product design in general. Designing a product that solves the wrong problems for a poorly-defined group isn’t exactly a recipe for success. [Benjie]’s advice on making a truly effective and useful API framework that genuinely lowers the bar of complexity in a useful way is similarly applicable to product design in general.

His first piece of advice is not to design for poorly-defined amorphous groups. Your product should serve actual needs of actual users. If you cannot name three people you have actually spoken to who would be helped by your product, you are designing for an amorphous (and possibly imaginary) group.

The second is to design as though your users are just as smart as you are, just less tolerant of problems stemming from rough edges like compatibility and configuration issues. Remove those so that your users can get useful work done without having to re-invent the wheel, or resort to workarounds.

Robotic frameworks like ROS are useful and extensible, but whenever someone attempts to focus on creating a simplified framework, [Benjie] says they tend to step on the same rakes. It’s a mistake [Benjie] has committed himself, and see repeated by others. We think his advice is good product design advice in general, whether for designing APIs or something else.

Did you know there is a Guinness World Record for the smallest humanoid robot? We didn’t either, but apparently this is a challenge attracting multiple competitors. [Lidor Shimoni] had a red hot go at claiming the record, but came up ever so slightly short. Or tall.

The former record holder was measured at 141 mm, so [Lidor] had to beat that. He set about building a humanoid robot 95 mm tall, relying on off-the-shelf parts and 3D-printed components of his own design. An ESP32 served as the brains of the operation, while the robot, named Tiny Titan, got big flat feet to make walking relatively stable and controlled. Small servos were stacked up to actuate the legs and create a suitably humanoid robot to claim the title.

Sadly, [Lidor] was pipped to the post. Some procrastinating in finishing the robot and documentation saw another rival with a 60mm robot take the record. It’s not 100% clear what Guinness requires for someone to take this record, but it seems to involve a robot with arms, legs, and some ability to walk.

Sometimes robots are more fun when they’re very small. If you’re developing your own record-breaking automatons, drop us a line won’t you?