adi_imu - ROS2 driver for for ADI's IMUs

::: {.contents depth=”2”} :::

Overview

Analog Devices offers a series of precision, miniature microelectromechanical system (MEMS) inertial measurement units (IMUs) that include a triaxial gyroscope and a triaxial accelerometer. Each inertial combines with signal conditioning that optimizes dynamic performance.

The factory calibration characterizes each sensor for sensitivity, bias, alignment, linear acceleration (gyroscope bias), and point of percussion (accelerometer location). As a result, each sensor has dynamic compensation formulas that provide accurate sensor measurements over a broad set of conditions.

Getting Started

To help you quickly get started with the adi_iio package, we have organized detailed documentation into several sections:

• For information on prerequisites, repository setup, and building the package, please refer to the Using imu-ros2 repository section.
• For information on running the adi_imu node with a local client or a remote client, please refer to the Run adi_imu node section.
• For information on topics, parameters, and examples, please refer to the adi_imu node description section.
• For example on how to use the adi_imu node, please refer to the Examples section.

Getting Help

• Issue Tracker: Report bugs, request features, or submit technical queries via our Issue Tracker.
• Further Guidance: For additional communication guidelines, refer to COMMUNICATION.

Contributing

Contributions are key to our project’s success. Before submitting changes:

• Familiarize yourself with our code and testing conventions.
• Consult the CONTRIBUTING.md for detailed instructions.
• Ensure your code adheres to our design values and guidelines.

License

This project is licensed under the Apache License, Version 2.0 LICENSE.

Changelog

Refer to our CHANGELOG file for version history and release notes.

Supported Devices

• ADIS16465
• ADIS16467
• ADIS16470
• ADIS16475
• ADIS16477
• ADIS16500
• ADIS16501
• ADIS16505
• ADIS16507
• ADIS16545
• ADIS16547
• ADIS16575
• ADIS16576
• ADIS16577

Applications

• Navigation, stabilization, and instrumentation
• Unmanned and autonomous vehicles
• Smart agriculture and construction machinery
• Factory/industrial automation, robotics
• Virtual/augmented reality
• Internet of Moving Things

Using imu-ros2 repository

This repository implements a ROS2 node that reads data from ADI IMU devices and publishes the read data on various topics. The node is also able to configure the IMU devices.

Prerequisites

imu-ros2 can be used with ROS2 humble distribution. To install it you may follow the documentation available here: https://docs.ros.org/en/humble/Installation.html

File truncated at 100 lines see the full file

Contributing Guidelines

Thank you for your interest in contributing to imu-ros2. Whether it’s a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community.

Please read through this document before submitting any issues or pull requests to ensure we have all the necessary information to effectively respond to your bug report or contribution.

Table of Contents:

• Contributing Guidelines
  • How to Contribute
    • Contributing source code
      • How to Contribute Source Code
      • Pull Request Rules
    • Bug reports
      • Before Submitting a Bug Report
      • How to Submit a Good Bug Report
    • Feature Requests
      • Before Submitting an Enhancement Suggestion
      • How to Submit a Good Enhancement Suggestion
    • Contributing documentation
      • Documentation Best Practices
  • Becoming a Trusted Committers
  • Licensing
  • Resources:

How to Contribute

Contributing source code

We follow a development process designed to reduce errors, encourage collaboration, and make high quality code. Review the following to get acquainted with this development process.

How to Contribute Source Code

• Create a fork of this repository. This will create your own personal copy of the package. All of your development should take place in your fork. If you are not sure how to do this, check out GitHub help

  • Create a create a remote pointing to the upstream remote repository.

  • Work out of a new branch, one that is not a release main branch, ideally a develop branch targeted for the currently supported ROS distribution, such as humble-develop. Remember to periodically rebase to have the latest code available.

• Write your code and remember to:
  • Always keep your branch updated with the original upstream.
  • Always sign-off you commits.
  • Look at the existing code and try to maintain the existing style and pattern as much as possible.

• Resolve compiler warnings or at least make sure you code does not add new ones.

• Submit a pull request to the upstream repository following the PR rules.

• Check Continuous Integration (CI): the moment you submit a pul request, a few jobs will be started which try to compile the code and run automated tests. Pay attention to any CI failures reported in the pull request, and stay involved in the conversation. On the Github UI, checks can be:
  • ✅: Passed, all good!
  • 🟡: Pending, results haven’t been received yet.
  • ❌: Failed, something is wrong.

Pull Request Rules

• Commit message includes a Signed-off-by: [name] < email > to the commit message. This ensures you have the rights to submit your code, by agreeing to the Developer Certificate of Origin. If you can not agree to the DCO, don’t submit a pull request, as we can not accept it.

  • DCO is a declaration of ownership, basically saying that you created the contribution and that it is suitable to be covered under an open source license (not proprietary).

  • If your user.name and user.email configurations are set up in git, then you can simply run git commit -signoff to have your signature automatically appended.

• Commit should be atomic, meaning it should do one thing only. A pull request may contain multiple commits if necessary to fix a bug or implement a feature.
• Commits should have good commit messages. Check out The git book for some pointers and tools to use.
• Typically, the title of the commit should have the path to the changed dir/[file], and then explaining in a few words what has been done, like: ci: add style check workflow for cpp files
• Write a concise PR description, containing all the needed details.
• Pull requests will be merged only after they have been reviewed, tested and approved by the code owners.

Bug reports

Before Submitting a Bug Report

Before creating a new issue, please search the repository’s open and recently closed issues to see if the same or a similar problem has already been reported. If the issue exists and is still open, add a comment to that issue. Otherwise, feel free to create a new one.

How to Submit a Good Bug Report

To help us resolve issues effectively, follow these guidelines when creating a bug report:

1. Use a clear and descriptive title to summarize the problem.
2. Describe the exact steps to reproduce the issue in detail. Provide enough information for someone to follow your steps exactly.
3. Include specific examples such as links to files, projects, or copy-pasteable snippets that demonstrate the issue.
4. Describe the observed behavior after performing the steps and explain what the problem is with that behavior.
5. Explain the expected behavior and why it differs from the observed behavior.
6. Attach screenshots or GIFs to visually demonstrate the issue whenever possible.

File truncated at 100 lines see the full file