Open Source RoboticsRobots, software & learning

Humanoid elevation-frame integration

Software

Humanoid lidar/elevation-mapping integration with additional gravity and robot-frame transformation scripts. [1] [2] [3] [4] [5] [6] [7] [8]

Installation & first result →Official websiteGetting started

For
Robotics developers evaluating the selected source workflow [1] [2] [3] [4] [5] [6] [7] [8]
Hardware
Upstream MID-360 lidar/humanoid frame setup [1] [6] [7]
Source rights
Some licenses are unresolved. Review licenses
Unknowns
operating system, compute requirements not fully established. Review gaps

Source researched · Not tested by us
Sources checked · Research details

Licenses & related hardware
License
not fully assessed for software, documentation · Details by part

Requirements · Research details and dates

On this page

Overview

This repository integrates MID-360 lidar/inertial odometry with humanoid elevation mapping. It credits ANYbotics elevation mapping and FAST-LIO-related work; the contribution described here is engineering integration and additional frame scripts, not a new mapping algorithm or reproduced perception result. [1] [6] [7]

Its README clone command names smoggy-P/elevation_mapping_humanoid, while this entry preserves the inspected ArthurAllshire repository identity. Comparing the stated revisions found 236 identical blob paths, ten changed common paths and three candidate-only files. The added gravity-correction and corrected-frame scripts provide a concrete distinction beyond a simple mirror. That comparison does not establish a preferred canonical maintainer or justify silently substituting repositories. [9]

The documented setup uses ROS/catkin, grid_map, kindr, PCL, Eigen and a Livox driver. The README requires source changes in specified preprocessing/mapping files when choosing driver2 instead of driver1. The inspected laserMapping.cpp already includes livox_ros_driver2/CustomMsg.h. Inspect preprocess.h, preprocess.cpp and laserMapping.cpp at this revision before applying the README replacements; consistency across all three files is not established by the supplied excerpts. Its realsense_demo.launch name should not substitute for inspecting the actual MID-360 topics/configuration. No workspace was built or launch run. [1] [4]

Inspect fast_lio_mid360/script/publish_tf.py for mount transforms. The candidate-specific gravity_correction_publisher.py consumes /livox/imu, averages initial samples and corrects odom_torso toward odom_corrected, using a hard-coded axis convention described as trial-and-error. The publish_corrected_frame.py script publishes height_map_2 using torso_link translation and yaw-only orientation. The README's map-output check is /elevation_mapping/elevation_map; none of those frames or outputs was validated here. These are actual implementation assumptions to inspect against the sensor/torso frame tree, not measured extrinsics or universally correct gravity alignment. No map, TF tree or sensor data was validated. [6] [7]

The inherited directories carry separate BSD-style and GPL notices; no blanket grant for the new integration scripts was established. Public source is not permission over every component. Begin with the exact sensor frames, mounts and driver variant, then inspect the additional frame scripts and map-output topic. No native dependency build, lidar/IMU session, map accuracy, locomotion or real-time performance was tested. [1] [2] [5] [6]

Is this for you?

Known limitations
  • README clones a different smoggy-P target; exact comparison finds shared code plus candidate-specific frame scripts, not a new mapping algorithm.
  • Inherited directory BSD/GPL notices do not establish a blanket grant for new integration scripts.
  • Hard-coded trial/error IMU axis convention and fixed averaging need robot-specific validation; no map or TF runtime tested.
  • laserMapping.cpp already includes driver2; consistency with both preprocessing files must be inspected before README substitutions.

Editorial assessment of bounded source evidence; no runtime, fit, manufacturing or compatibility proof.

[1] [2] [3] [4] [5] [6] [7] [8] · Editorial assessment

What you need

Languages / runtimes
  • C++ ROS mapping integration and Python frame/IMU scripts.

Source-reported requirement/configuration, not a tested installation, compatibility matrix or measured runtime result.

[3] [4] [6] [7]

Dependencies
  • ROS catkin, grid_map, kindr, PCL, Eigen and compatible Livox driver
  • Exact lidar/IMU/torso frame tree and sensor extrinsics; driver1/driver2 source changes differ

[1] [2] [3] [4] [5] [6] [7] [8]

Installation & first result

Open the upstream getting-started guide [1] [2] [3] [4] [5] [6] [7] [8]

  • Inspect the pinned implementation and select the exact configuration described in the article.
  • Follow the chosen upstream environment/build route, resolving the listed dependencies before runtime or hardware integration.

Editorial assessment of bounded source evidence; no runtime, fit, manufacturing or compatibility proof.

[1] [2] [3] [4] [5] [6] [7] [8] · Editorial assessment

Installation

Documented ROS catkin route after Livox driver setup; README clones smoggy-P while this inspected ArthurAllshire revision adds frame scripts. Check existing driver2 include and preprocessing consistency before applying replacements.

Source-reported requirement/configuration, not a tested installation, compatibility matrix or measured runtime result.

[1] [4] [6] [7] [9]

Hardware, models & data

Supported hardware
  • Upstream MID-360 lidar/humanoid frame setup; robot-specific mount/extrinsic adaptation required and unverified.

Source-reported requirement/configuration, not a tested installation, compatibility matrix or measured runtime result.

[1] [6] [7]

What we checked

Pinned source and selected artifact structure review only; no dependency installation, upstream build, native CAD/kernel/fit/strength validation, fabrication, wiring, calibration, simulation, powered operation or performance testing. Original archives stay private.

Not yet established

  • Requirements: operating system, host computer

Updates

Upstream last updated
Not established
Latest release
Not established
Profile updated
Nov 1, 2026
Sources last checked
Nov 1, 2026
Next review
Dec 1, 2026
Reviewed revision
214bc3f

Source files and licenses

Distinct inspectable robotics software/data workflow with specific contribution and bounded next source-investigation step; not performance or physical-build certification.

LayerAvailability / license
softwareavailable · License not fully assessed
Selected project implementation; external dependencies, hardware, weights/data and asset rights remain separate. [6]
documentationavailable · License not fully assessed
Scoped project declaration; no blanket grant over all linked material. [1]

Outside the selected contribution; no separate released layer claimed.

References

Each source links to the exact revision we read. “Used for” shows where this page relies on it.

Correction guidance · Discussion is not enabled · Profile format 0.7.0-draft.5

Change history