I’m not saying that the magic pocket oracle we all carry around isn’t great, but I think there is a philosophical disconnect between what it is and what it could be for us. Right now our technology is still trying to improve every tool except the one we use the most, our brain.
At first this seems like a preposterous claim. Doesn’t Google Maps let me navigate in completely foreign locations with ease? Doesn’t Evernote let me off-load complicated knowledge into a magic box somewhere and recall it with photo precision whenever I need to? Well, yes, they do, but they do it wrong. What about ordering food apps? Siri? What about all of these. Don’t they dramatically extend my ability? They do, but they do it inefficiently, and they will always do it inefficiently unless there is a philosophical change in how we design our tools.
We would be more excited if we knew how much it costs, but in principle the device is super cool. From a robotics research perspective it’s a sort of perfect package. ROS is a wonderful distributed and asynchronous robotic operating system, test, and development platform. The Intel developers designed this unit around the needs of ROS and it comes pre-installed on the camera.
For those who haven’t used ROS before, this is a really cool feature. ROS is natively distributed. It really doesn’t care where the computer supplying its data lives. So, for example, if you already had a robot and wanted to add stereo vision to it. You could offload all the vision processing components of your existing ROS codebase to the Euclid and continue as if nothing changed.
The other option is to use the board as the entire robot brain. It’s self contained with battery and camera. It’s a USB to serial connection away from supercharging any small robotics project.
Unfortunately the board is still a demo, and based on Intel’s history, likely to be too expensive to lure ordinary hackers away from the RasPis and import cameras they already know how to hack together into more or less the same thing. Universities will likely be weak at the knees for such a development though.
Almost every big corporation has a research and development organization, so it came as no surprise when we found a tip about Disney Research in the Hackaday Tip Line. And that the project in question turned out to involve human-safe haptic telepresence robots makes perfect sense, especially when your business is keeping the Happiest Place on Earth running smoothly.
That Disney wants to make sure their Animatronics are safe is good news, but the Disney project is about more than keeping guests healthy. The video after the break and the accompanying paper (PDF link) describe a telepresence robot with a unique hydrostatic transmission coupling it to the operator. The actuators are based on a rolling-diaphragm design that limits hydraulic pressure. In a human-safe system that’s exactly what you want.
The system is a hybrid hydraulic-pneumatic design; two actuators, one powered by water pressure and the other with air, oppose each other in each joint. The air-charged actuators behave like a mass-efficient spring that preloads the hydraulic actuator. This increases safety by allowing the system to be de-energized instantly by venting the air lines. What’s more, the whole system presents very low mechanical impedance, allowing haptic feedback to the operator through the system fluid. This provides enough sensitivity to handle an egg, thread a needle — or even bop a kid’s face with impunity.
[Fred Hoefler] was challenged to finally do something with that Raspberry Pi he wouldn’t keep quiet about. So he built a machine assist loom for the hand weaver. Many older weavers simply can’t enjoy their art anymore due to the physical strain caused by the repetitive task. Since he had a Pi looking for a purpose, he also had his project.
His biggest requirement was cost. There are lots of assistive looms on the market, but the starting price for those is around ten thousand dollars. So he set the rule that nothing on the device would cost more than the mentioned single board computer. This resulted in a BOM cost for the conversion that came in well under two hundred dollars. Not bad!
The motive parts are simple cheap 12V geared motors off Amazon. He powered them using his own motor driver circuits. They get their commands from the Pi, running Python. To control the loom one can either type in commands into the shell or use the keyboard. There are also some manual switches on the loom itself.
In the end [Fred] met his design goal, and has further convinced his friends that the words Raspberry Pi are somehow involved with trouble.
For humans, moving our arms and hands onto an object to pick it up is pretty easy; but for manipulators, it’s a different story. Once we’ve found the object we want our robot to pick up, we still need to plan a path from our robot hand to the object all the while lugging the remaining limbs along for the ride without snagging them on any incoming obstacles. The space of all possible joint configurations is called the “joint configuration space.” Planning a collision-free path through them is called path planning, and it’s a tricky one to solve quickly in the world of robotics.
These days, roboticists have nailed out a few algorithms, but executing them takes 100s of milliseconds to compute. The result? Robots spend most of their time “thinking” about moving, rather than executing the actual move.
It’s worth asking: why is this problem so hard? How did hardware make it faster? There’s a few layers here, but it’s worth investigating the big ones. Planning a path from point A to point B usually happens probabilistically (randomly iterating to the finishing point), and if there exists a path, the algorithm will find it. The issue, however, arises when we need to lug our remaining limbs through the space to reach that object. This feature is called the swept volume, and it’s the entire shape that our ‘bot limbs envelope while getting from A to B. This is not just a collision-free path for the hand, but for the entire set of joints.
Encoding a map on a computer is done by discretizing the space into a sufficient resolution of 3D voxels. If a voxel is occupied by an obstacle, it gets one state. If it’s not occupied, it gets another. To compute whether or not a path is OK, a set of voxels that represent the swept volume needs to be compared against the voxels that represent the environment. Here’s where the FPGA kicks in with the speed bump. With the hardware implementation, voxel occupation is encoded in bits, and the entire volume calculation is done in parallel. Nifty to have custom hardware for this, right?
We applaud the folks at Duke University for getting this up-and-running, and we can’t wait to see custom “robot path-planning chips” hit the market some day. For now, though, if you’d like to sink your teeth into seeing how FPGAs can parallelize conventional algorithms, check out our linear-time sorting feature from a few months back.
Boston Dynamics, the lauded robotics company famed for its ‘Big Dog’ robot and other machines which push mechanical dexterity to impressive limits have produced a smaller version of their ‘Spot’ robot dubbed ‘SpotMini’.
A lightweight at 55-65 lbs, this quiet, all-electric robot lasts 90 minutes on a full charge and boasts partial autonomy — notably in navigation thanks to proprioception sensors in the limbs. SpotMini’s most striking features are its sleek new profile and manipulator arm, showing off this huge upgrade by loading a glass into a dishwasher and taking out some recycling.
Robots are prone to failure, however, so it’s good to know that our future overlords are just as susceptible to slipping on banana peels as we humans are.
One of the features of fancy modern industrial motor and controller sets is the ability for the motor to act as a mass-spring-damper. For example, let’s say you want a robot to hold an egg. You could have it move to the closed position, but tell the controller you only want to use so much force to do it. It will hold the egg as if there was a spring at its joint.
Another way you could use this is in the application of a robot leg. You tell the controller what kind of spring and shock absorber (damper) combination it is and it will behave as if those parts have been added to the mechanism. This is important if you want a mechanical leg to behave like a biological leg.
[Ben] had worked on a more formal project which used some very expensive geared motors to build a little running robot. It looks absolutely ridiculous, as you can see in the following video, but it gives an idea of where he’s going with this line of research. He wanted to see if he could replace all those giant geared motors with the cheap and ubiquitous high performance brushless DC motors for sale now. Especially given his experience with them.
So far he’s done a very impressive amount of work. He’s built a control board. He’s characterized different motors for the application. He’s written a lot of cool software; he can even change the stiffness and damping settings on the fly. He has a single leg that can jump. It’s cool. He’s taking a hiatus from the project, but he’ll be right back at it soon. We’re excited for the updates!