-
 

ping360_sonar repository

Repository Summary

Checkout URI https://github.com/CentraleNantesRobotics/ping360_sonar.git
VCS Type git
VCS Version master
Last Updated 2022-03-23
Dev Status MAINTAINED
CI status No Continuous Integration
Released UNRELEASED
Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

Name Version
ping360_sonar 1.4.0

README

ping360_sonar

GitHub stars GitHub forks Build Status GitHub issues GitHub license Github all releases GitHub release All Contributors

Overview

A python ROS package for the BlueRobotics Sonar. The package has been tested under ROS melodic and Ubuntu 16.04. This code is mostly experimental, expect that it changes often.

Keywords: ROS, package, ping360, ping360 emulator

License

The source code is released under a MIT license.

Installation

Download the latest release

Get the latest stable release here.

Building from Source

Dependencies

Building

Before building from source, install ping-protocol python lib:

pip install bluerobotics-ping

!Headsup! B.R. just updated their package with some breaking changes, make you sure you use version 0.0.9 for now.

To build from source, clone the latest version from this repository into your catkin workspace and compile the package using

cd catkin_workspace/src
git clone https://github.com/CentraleNantesRobotics/ping360_sonar.git
cd ../
catkin build

Unit Tests

TODO

Usage

An example launch file has been provided example.launch:

Run the main node with:

roslaunch ping360_sonar example.launch

Launch files

  • example.launch: contains the default parameteres to run the Ping360 Sonar, including the serial port and the baudrate to interface with the sonar. The rest of the parameters are documented here: Ping360 Documentation. The same parameters can also be reconfigured using the dynamic_reconfigure.

    An emulated mode was added to test the package when you don’t have the sonar. To run the emulated sonar, set the env variable to “true”:

      <env name="emulated_sonar" value="true" />
    

    The results from the emulation should be:

alt img

Three extra parameters can be set to toggle specific topics, they are set to true by default.

    <param name="enableImageTopic" value="True or False"/> 
    <param name="enableScanTopic" value="True or False"/> 
    <param name="enableDataTopic" value="True or False"/>

By default, the sensor does a full 360° rotation, but that can be changed by modifying the min and max scan angle values.

    <param name="minAngle" value="0"/> 
    <param name="maxAngle" value="400"/> 

Please note that these angle value are in GRAD and not DEG.

You can also enable or disable the sensor oscillation by setting the oscillate parameter.

    <param name="oscillate" value="True or False"/> 

Nodes

ping360_node

While continuously rotating the sonar in a set FOV range (defined by the min and max angle parameters), it publishes two types of messages:

  • The sonar’s response data (the echo intensities for a given angle & range)
  • A LaserScan msg with ranges detected using a certain intensity threshold:
  • A black and white image using the date received from the sonar. Same as the one generated by the ping viewer.

Published Topics

  • /ping360_node/sonar/images (sensor_msgs/Image)

    The generated sonar image. This topic can be toggled using the enableImageTopic parameter.

  • /ping360_node/sonar/data (msg/SonarEcho)

    Publishes the raw sonar data in a custom message:

      Header header            #header info
      float32 angle               # the measurement angle [rad]
      uint8 gain  # Sonar Gain
      uint16 number_of_samples 
      uint16 transmit_frequency # [kHz]
      uint16 speed_of_sound # [m/s]
      uint8 range      #  range value [m]
      uint8[] intensities    # intensity data [0-255].  This is the actual data received from the sonar
    

    This topic can be toggled using the enableDataTopic parameter.

  • /ping360_node/sonar/scan (sensor_msgs/LaserScan)

    Publishes a LaserScan msg with ranges detected above a certain intensity threshold:

      float32 angle_min = minAngle     # start angle of the scan [rad]
      float32 angle_max = maxAngle  # end angle of the scan [rad]
      float32 angle_increment   # angular distance between measurements, calculated using the configured Step  [rad]
    
      float32 range_min = .75   # minimum range value [m]
      float32 range_max = sonarRange # maximum range value, it's set to the configured sonarRange [m]
    
      float32[] ranges         # calculated ranges that correspond to an intensity > threshold [m] 
      float32[] intensities    # sensor intensity data [0-255]
    

    This topic can be toggled using the enableScanTopic parameter.

    Note:

    • ranges values < range_min or > range_max should be discarded
    • don’t forget to set the frame to sonar_frame when using Rviz

Bugs & Feature Requests

Please report bugs and request features using the Issue Tracker.

Contributors


Henrique Martinez Rocamora

💻 ⚠️

Anas Mazouni

💻 ⚠️

tomlogan501

🤔 ⚠️ 🐛

This project follows the all-contributors specification.

Contributions of any kind welcome! Please refer to our Contribution Guide

CONTRIBUTING

Contributing to this package

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

We’re really glad you’re reading this, because we need volunteer developers to help improve this project.

First, here are some resources:

Testing

TODO

Linting

You may notice that a CI job is triggered after every new push, these CIs assure that the code format follows the PEP8 standard imposed by the ROS team. To make sure your changes are well formatted, we supplied a pre-commit config file that can be used to verify code formatting before commit.

Installing “pre-commit”

pre-commit is written in python and can be easily installed using : ```pip install pre-commit


### Configuring "pre-commit"

In your local repo folder, execute 
```pre-commit install
``` to install git hooks in your .git/ directory.

### Using "pre-commit"

Once you're ready to commit your new changes, run :

$ git add . $ git commit -m “Commit message CHANGE ME”

This will trigger the pre-commit hook and output the following:

autopep8………………………………………………………..Passed/Failed Flake8………………………………………………………….Passed/Failed [develop f726bfe] Add the minAngle parameter + readme update 3 files changed, 51 insertions(+), 17 deletions(-)

```

If everything goes well, your changes will be commited. If there’s an issue autopep8 will try to fix it (don’t forget to stage the new edits), so just run the commit command a second time. I also recommend installing autopep8 using pip and using it as a formatter in you’re IDE. (VS Code has that by default).

For more info about using precommits, please refer to : https://ljvmiranda921.github.io/notebook/2018/06/21/precommits-using-black-and-flake8/

Submitting changes

Please send a GitHub Pull Request with a clear list of what you’ve done (read more about pull requests). When you send a pull request, we will love you forever if you update the README or add tests too. We can always use more tests. Please follow our coding conventions (below) and make sure all of your commits are atomic (one feature per commit).

Always write a clear log message for your commits. One-line messages are fine for small changes, but bigger changes should look like this:

$ git commit -m "A brief summary of the commit
> 
> A paragraph describing what changed and its impact."

Coding conventions

Start reading our code and you’ll get the hang of it. We optimize for readability:

  • We indent using two spaces (soft tabs)
  • We ALWAYS put spaces after list items and method parameters ([1, 2, 3], not [1,2,3]), around operators (x += 1, not x+=1), and around hash arrows.
  • This is open source software. Consider the people who will read your code, and make it look nice for them. It’s sort of like driving a car: Perhaps you love doing donuts when you’re alone, but with passengers the goal is to make the ride as smooth as possible.

Thanks, Anas @ Centrale Nantes Robotics