|CI status||No Continuous Integration|
|Package Tags||No category tags.|
Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)
Keywords: ROS, package, ping360, ping360 emulator
The source code is released under a MIT license.
Download the latest release
Get the latest stable release here.
Building from Source
Before building from source, install ping-protocol python lib:
pip install bluerobotics-ping
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
An example launch file has been provided example.launch:
Run the main node with:
roslaunch ping360_sonar example.launch
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:
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"/>
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.
The generated sonar image. This topic can be toggled using the enableImageTopic parameter.
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.
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.
- 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.
Henrique Martinez Rocamora
🤔 ⚠️ 🐛
This project follows the all-contributors specification.
Contributions of any kind welcome! Please refer to our Contribution Guide
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:
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.
pre-commit is written in python and can be easily installed using :
pip install pre-commit
In your local repo folder, execute
to install git hooks in your .git/ directory.
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/
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."
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