Robots Collaborate To Localize Themselves Precisely

August 26, 2024 by Lewin Day 3 Comments

Here’s the thing about robots. It’s hard for them to figure out where to go or what they should be doing if they don’t know where they are. Giving them some method of localization is key to their usefulness in almost any task you can imagine. To that end, [Guy Elmakis], [Matan Coronel] and [David Zarrouk] have been working on methods for pairs of robots to help each other in this regard.

As per the research paper, the idea is to perform real-time 3D localization between two robots in a given location. The basic idea is that the robots take turns moving. While one robot moves, the other effectively acts as a landmark. The robots are equipped with inertial measurement units and cameras in a turret, which they use to track each other and their own movements. Each robot is equipped with a Raspberry Pi 4 for processing image data and computing positions, and the two robots communicate via Bluetooth to coordinate their efforts.

It’s an interesting technique that could have some real applications in swarm robotics, and in operations in areas where satellite navigation and other typical localization techniques are not practical. If you’re looking for more information, you can find the paper here. We’ve seen some other neat localization techniques for small robots before, too. Video after the break.

Continue reading “Robots Collaborate To Localize Themselves Precisely” →

RC car without a top, showing electronics inside.

Fast Indoor Robot Watches Ceiling Lights, Instead Of The Road

October 25, 2021 by Donald Papp 15 Comments

[Andy]’s robot is an autonomous RC car, and he shares the localization algorithm he developed to help the car keep track of itself while it zips crazily around an indoor racetrack. Since a robot like this is perfectly capable of driving faster than it can sense, his localization method is the secret to pouring on additional speed without worrying about the car losing itself.

The regular pattern of ceiling lights makes a good foundation for the system to localize itself.

To pull this off, [Andy] uses a camera with a fisheye lens aimed up towards the ceiling, and the video is processed on a Raspberry Pi 3. His implementation is slick enough that it only takes about 1 millisecond to do a localization update, netting a precision on the order of a few centimeters. It’s sort of like a fast indoor GPS, using math to infer position based on the movement of ceiling lights.

To be useful for racing, this localization method needs to be combined with a map of the racetrack itself, which [Andy] cleverly builds by manually driving the car around the track while building the localization data. Once that is in place, the car has all it needs to autonomously zip around.

Interested in the nitty-gritty details? You’re in luck, because all of the math behind [Andy]’s algorithm is explained on the project page linked above, and the GitHub repository for [Andy]’s autonomous car has all the implementation details.

The system is location-dependent, but it works so well that [Andy] considers track localization a solved problem. Watch the system in action in the two videos embedded below.

Continue reading “Fast Indoor Robot Watches Ceiling Lights, Instead Of The Road” →

Under The Sea GPS Uses Sound

November 8, 2020 by Al Williams 18 Comments

If you’ve ever tried to use GPS indoors, you know that the signals aren’t easy to acquire in any sort of structure. Now imagine trying to get a satellite fix underwater. Researchers at MIT have a new technique, underwater backscatter localization or UBL, that promises to provide a low-power localization system tailored for the subsea environment.

Like other existing solutions, UBL uses sound waves, but it avoids some of the common problems with using sonic beacons in that environment. A typical system has a fixed beacon constrained by the availability of power or battery-operated beacons that require replacement or recharging. Since the beacon acts as a transponder — it receives a signal and then replies — it requires either constant power or time to wake up from the external stimulus and that time typically varies with the environment. That variable startup time interferes with computing the round-trip time of the signal, which is crucial for estimating position.

Continue reading “Under The Sea GPS Uses Sound” →

Does Library Bloat Make Your Smartphone App Look Fat?

December 18, 2018 by Tom Nardi 53 Comments

While earlier smartphones seemed to manage well enough with individual applications that only weighed in at a few megabytes, a perusal of the modern smartphone software store uncovers some positively monstrous file sizes. The fact that we’ve become accustomed to mobile applications requiring 100+ MB downloads on what’s often a metered Internet connection in only a few short years is pretty crazy if you stop to think about it.

Seeing reports that the Nest app for iOS tipped the scales at nearly 250 MB, [Alexandre Colucci] decided to investigate. On his blog he not only documents the process of taking the application apart piece by piece to find out just what’s eating up all that space, but lists some potential fixes which could shave a bit off the top. Even if you aren’t planning a spelunking expedition into your pocket supercomputer’s particular variant of the Netflix app, the methodology and tools he uses here are fascinating in their own right and might be something worth adding to your software bag of tricks.

By passing the application’s files through a disk usage visualizer called GrandPerspective, [Alexandre] immediately identified some rather large blocks of content. The bundled Apple Watch version of the app takes up 23 MB, video and audio used to walk the user through the device setup weigh in at 22 MB, and localization files for various languages consumes a surprising 33 MB. But the biggest single contributor to the application’s heft is the assorted libraries and frameworks which total up to an incredible 67 MB.

Of course the question is, how much of it is really necessary? It’s hard to be sure from an outsider’s perspective, but [Alexandre] notes that a few of the libraries used seem to be redundant or obsolete. In some cases this could be the result of old code still lurking in the project, but the four different libraries used for user tracking probably aren’t in there by accident. It also stands to reason that the instructional videos could be offloaded to something like YouTube, so that only users who need to view them have to expend their bandwidth on it.

Getting a little deeper into things, [Alexandre] notes that some of the localization images appear to be redundant. As a specific example, he points to the images of the Nest itself displaying Fahrenheit and Celsius temperatures. While logically this should only be two image files, there are actually eight copies of the Celsius image, each filed away as language-specific. These redundant localization images could easily be stripped out, but with gains measured in only a few hundred kilobytes, it probably wasn’t considered worth the effort during development.

In the end there’s really not as much bloat as we might like to believe. There were some redundant files, maybe a few questionable library inclusions, and the Apple Watch version of the app could surely be separated out. All together, it might get you a savings of 30 – 40%, but still not enough to bring it down under 100 MB.

All signs point to the fact that modern smartphone software development is just a lot more burdensome than us hackers might like. Save for projects looking to put control back into the hand’s of the users, it looks like mobile operating systems aren’t going to be slimming down anytime soon.

Lighthouse Locates Drone; Achieves Autonomous Battery Swap

November 30, 2016 by Elliot Williams 21 Comments

The HTC Vive’s Lighthouse localization system is one of the cleverest things we’ve seen in a while. It uses a synchronization flash followed by a swept beam to tell any device that can see the lights exactly where it is in space. Of course, the device has to understand the signals to figure it out.

[Alex Shtuchkin] built a very well documented device that can use these signals to localize itself in your room. For now, the Lighthouse stations are still fairly expensive, but the per-device hardware requirements are quite reasonable. [Alex] has the costs down around ten dollars plus the cost of a microcontroller if your project doesn’t already include one. Indeed, his proof-of-concept is basically a breadboard, three photodiodes, op-amps, and some code.

His demo is awesome! Check it out in the video below. He uses it to teach a quadcopter to land itself back on a charging platform, and it’s able to get there with what looks like a few centimeters of play in any direction — more than good enough to land in the 3D-printed plastic landing thingy. That fixture has a rotating drum that swaps out the battery automatically, readying the drone for another flight.

If this is just the tip of the iceberg of upcoming Lighthouse hacks, we can’t wait!

Continue reading “Lighthouse Locates Drone; Achieves Autonomous Battery Swap” →

Absolute 3D Tracking With EM Fields

September 20, 2016 by Gerrit Coetzee 28 Comments

[Chris Gunawardena] is still holding his breath on Valve and Facebook surprising everyone by open sourcing their top secret VR prototypes. They have some really clever ways to track the exact location and orientation of the big black box they want people to strap to their faces. Until then, though, he decided to take his own stab at the 3D tracking problems they had to solve.

While they used light to perform the localization, he wanted to experiment with using electromagnetic fields to perform the same function. Every phone these days has a magnetometer built in. It’s used to figure out which way is up, but it can also measure the local strength of magnetic fields.

Unfortunately to get really good range on a magnetic field there’s a pesky problem involving inverse square laws. Some 9V batteries in series solved the high current DC voltage source problem and left him with magnetic field powerful enough to be detected almost ten centimeters away by his iPhone’s magnetometer.

As small as this range seems, it ended up being enough for his purposes. Using the existing math and a small iOS app he was able to perform rudimentary localization using EM fields. Pretty cool. He’s not done yet and hopes that a more sensitive magnetometer and a higher voltage power supply with let him achieve greater distances and accuracy in a future iteration.

KiCad Traducido Al Español

February 11, 2016 by Brian Benchoff 67 Comments

KiCad ya es una gran herramienta para la captura esquemática y el diseño de PCB, pero el software sólo funciona si es posible utilizarlo. Para los mil millones de personas que no hablan inglés, esto significa que el idioma es la barrera más grande al momento de utilizar el mejor software para desarrollo de hardware. En los últimos meses, [ElektroQuark] ha estado liderando esfuerzos de localización al español de KiCad y estos se encuentran finalmente completados. También ha iniciado un foro de KiCad en idioma español para llevar el desarrollo de software hacia uno de los idiomas más hablado del planeta.

Mientras que ha habido otros intentos por localizar KiCad a otros idiomas, la mayoría de estos proyectos se encuentran incompletos. En una actualización de KiCad hace algunos meses, la localización al español ya contaba con algunas cadenas ya traducidas, pero no demasiadas. Los esfuerzos de [ElektroQuark] han acercado KiCad a millones de hablantes nativos de español, no solo algunos de sus menús.

El español es la segunda lengua más hablada del planeta, mientras que el inglés es la tercera. Teniendo en cuenta solamente este hecho, parece absurdo que casi todas las herramientas de software para capturas esquemáticas y diseño de PCB sean localizados sólo al chino o al inglés. Los esfuerzos de [ElektroQuark] por localizar KiCad al español son un gran avance para un ya impresionante software.