Skip to content

Home

Jump to bottom
wzli edited this page Apr 18, 2020 · 18 revisions

Code Map Localization is an indoor 2D localization system that decodes floor printed binary patterns to achieve robust and accurate global positioning. The algorithm is designed to run in real-time under tight resource constraints (ie embedded micro-controllers), and works with image sensors as low as 20x20 pixels in resolution.

Currently supports:

  • USB cameras
  • ESP32 camera
  • PC simulation
  • ROS2 interface
  • Python binding

Use cases

Although many applications exist, the primary objective is to provide a reliable and extremely low-cost localization system for large fleets of autonomous indoor ground vehicles, as other existing systems usually become prohibitively expensive as the coverage area and fleet size scales up.

Case Examples:

  • For research purposes, it is often required to collect real-time “ground truth” localization data for mobile robots to evaluate various control and estimation algorithms.
  • For industrial purposes, autonomous warehouse robots often require accurate real-time localization data in order to maneuver in tight spaces and arrive at exact locations for loading/unloading/docking.
  • For hobbyist purposes, small robotics demos often require a localization system that is robust and portable with minimal setup (the floor pattern can be printed on a portable surface).

Compared to other methods

See Comparing Indoor Localization Systems, in brief:

Advantages:

  • Millimeter accurate global positioning everywhere. It is literally “ground truth”.
  • High update frequency, limited only by image sensor framerate.
  • Scales to any number of trackers without penalty.
  • Ultra-low cost.
    • Each module requires as much hardware as an optical mouse, which is a few dollars at scale.
      • The current development prototype cost less than $10 each.
    • Graphic flooring might be an investment depending on material. For reference, custom printed vinyl flooring stickers are about $5 per square meter at scale.
      • For demo purposes even a large format poster would suffice.
  • Can use and share existing imaging systems without requiring dedicated hardware. (Any floor pointing camera)

Drawbacks:

  • 2D only.
  • Requires floor printed positioning pattern.
  • Loses localization during high-speed motion.
    • Mostly dependent on camera configuration, image may be too smeared to decode at some movement threshold, especially for rolling shutter.
    • Visual odometry requires some overlap between successive frames, which decreases with movement speed.

Frequently Asked Questions

How large of an area can the system cover?

Coverage area depends on block size of the code used, which is configurable according to camera sensor quality and image processing resources. For reference, currently a block of 20x20 bits (containing up to ~20% random bit errors) can decode about 50,000 positions per axis, which translates to 50m by 50m if every bit is printed at 1mm (ie millimeter accuracy)

What makes this better than similar systems/algorithms that already exist?

  1. It is free and open-source.
  2. It is a complete localization system that works out of the box.
  3. It is designed for practical application, to run in real-time on common low cost hardware with meager resources.
  4. The core algorithm is portable to different systems, currently supporting simulation, usb camera, and embedded platforms.
  5. The binary code sequence embeds both position and direction data, which allows global heading/orientation to be decoded along with x and y position coordinates.

How does it work?

See wiki on implementation details.

How far does the camera have to be from the floor pattern?

It depends on how large the floor pattern is printed and the lens configuration of the image sensor. Ideally the length of 1 bit in the floor pattern should be projected onto 1.5 to 3 pixels on the sensor. For a crude reference, if the pattern is printed at 1mm resolution, the camera distance should be between 10cm - 20cm for a typical 60 degree FOV webcam.

Does the camera have to point perpendicular to the floor?

The short answer is YES. This is a choice by design because estimating and undoing image perspective distortions every frame in software requires higher computation and source resolution, which is not worth the trade-off considering micro-controller resources and the primary use case of fixed mounting a floor pointed camera for 2D navigation. However, usually there is some leeway virtue of bit error correction mechanisms and code redundancy across the frame.

Clone this wiki locally