Robotic Boat Rides High On PVC Pipe Pontoons

If you want to build your own rover, there’s plenty of cheap RC trucks out there that will provide a serviceable chassis to work with. Looking to go airborne with a custom drone? Thanks to the immense popularity of first-person view (FPV) flying, you’ll find a nearly infinite variety of affordable fixed wing and quadcopter platforms out there to chose from. But when it comes to robotic watercraft, the turn-key options aren’t nearly as plentiful; the toys are all too small, and the commercial options are priced for entities that have an R&D budget to burn. For amateur aquatic explorers, creativity is the name of the game.

Take for example this impressive vessel built by [wesgood]. With a 3D printed electronics enclosure mounted to a pair of pontoons made of cheap 4-inch PVC pipe available from the hardware store, it provides a stable platform without breaking the bank. Commercial jet drive units built into the printed tail caps for the pipes provide propulsion, and allow the craft to be steered through differential thrust. Without rudders or exposed propellers, this design is particularly well-suited for operating in shallow waters.

A removable electronics tray allows for easy access.

Perched high above the water, the electronics box contains a Raspberry Pi 2, BU353 USB GPS receiver, and a Arduino Mega 2560 paired with a custom PCB that offers up convenient ports to connect a dual-channel Cytron 3 amp motor driver and Adafruit BNO055 9-DOF IMU. Power is provided by two 6,000 mAh LiPo batteries mounted low in the pontoons, and a matching pair of Adafruit current/voltage sensors are used to keep track of the energy budget. A small USB WiFi dongle with an external antenna plugged into the Pi offers up a WiFi network that [wesgood] can connect to with an iPad for control.

If the control software for the craft looks particularly well-polished, it’s probably because [wesgood] just so happens to be a professional developer with a focus on mobile applications. While we’re a bit skeptical of using WiFi for a critical long-distance link, we can’t deny that the iPad allows for a very slick interface. In addition to showing the status of the craft’s various systems, it lets the user either take manual control or place waypoints for autonomous navigation — although it sounds like that last feature is only partially implemented right now.

We love this design, and are eager to see more as the project develops. Recently [wesgood] experimented with payloads that can be suspended from the bottom of the electronics box, specifically a sonar module for performing bathymetric observations. There’s considerable interest in crowd sourced depth maps for inland waterways, and a robotic craft that can reliably chart these areas autonomously is certainly a step up from having to collect the data manually.

MIT Breaks Autonomous Drone Speed Limits By Not Sweating Obstacles

How does one go about programming a drone to fly itself through the real world to a location without crashing into something? This is a tough problem, made even tougher if you’re pushing speeds higher and high. But any article with “MIT” implies the problems being engineered are not trivial.

The folks over at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) have put their considerable skill set to work in tackling this problem. And what they’ve come up with is (not surprisingly) quite clever: they’re embracing uncertainty.

Why Is Autonomous Navigation So Hard?

Suppose we task ourselves with building a robot that can insert a key into the ignition switch of a motor vehicle and start the engine, and could do so in roughly the same time-frame that a human could do — let’s say 10 seconds. It may not be an easy robot to create, but we can all agree that it is very doable. With foreknowledge of the coordinate information of the vehicle’s ignition switch relative to our robotic arm, we can place the key in the switch with 100% accuracy. But what if we wanted our robot to succeed in any car with a standard ignition switch?

Now the location of the ignition switch will vary slightly (and not so slightly) for each model of car. That means we’re going to have to deal with this in real time and develop our coordinate system on the fly. This would not be too much of an issue if we could slow down a little. But keeping the process limited to 10 seconds is extremely difficult, perhaps impossible. At some point, the amount of environment information and computation becomes so large that the task becomes digitally unwieldy.

This problem is analogous to autonomous navigation. The environment is always changing, so we need sensors to constantly monitor the state of the drone and its immediate surroundings. If the obstacles become too great, it  creates another problem that lies in computational abilities… there is just too much information to process. The only solution is to slow the drone down. NanoMap is a new modeling method that breaks the artificial speed limit normally imposed with on-the-fly environment mapping.

Continue reading “MIT Breaks Autonomous Drone Speed Limits By Not Sweating Obstacles”

Stereo Vision And Depth Mapping With Two Raspi Camera Modules

The Raspberry Pi has a port for a camera connector, allowing it to capture 1080p video and stream it to a network without having to deal with the craziness of webcams and the improbability of capturing 1080p video over USB. The Raspberry Pi compute module is a little more advanced; it breaks out two camera connectors, theoretically giving the Raspberry Pi stereo vision and depth mapping. [David Barker] put a compute module and two cameras together making this build a reality.

The use of stereo vision for computer vision and robotics research has been around much longer than other methods of depth mapping like a repurposed Kinect, but so far the hardware to do this has been a little hard to come by. You need two cameras, obviously, but the software techniques are well understood in the relevant literature.

[David] connected two cameras to a Pi compute module and implemented three different versions of the software techniques: one in Python and NumPy, running on an 3GHz x86 box, a version in C, running on x86 and the Pi’s ARM core, and another in assembler for the VideoCore on the Pi. Assembly is the way to go here – on the x86 platform, Python could do the parallax computations in 63 seconds, and C could manage it in 56 milliseconds. On the Pi, C took 1 second, and the VideoCore took 90 milliseconds. This translates to a frame rate of about 12FPS on the Pi, more than enough for some very, very interesting robotics work.

There are some better pictures of what this setup can do over on the Raspi blog. We couldn’t find a link to the software that made this possible, so if anyone has a link, drop it in the comments.