ros / common_msgs Goto Github PK

In this line, You disable DELETEALL enum.
I am using indigo ros. And in the wiki, you mention DELETEALL functionality.
I was surprise that in there is not DELETEALL enum value on the code.
So I hack the value from the wiki, and it work! :)
Why not enable it for all?

I've built the "sensor_msgs" module from source and installed it with the following command:

catkin_make_isolated --install --pkg sensor_msgs

It works perfectly fine with other packages from the "common_msgs" repository (like "geometry_msgs" etc). But the "sensor_msgs" module wasn't recognized by Python. I got this error:

Traceback (most recent call last):
  File "/var/lib/cloud9/catkin_ws/src/bbot/scripts/imu_publisher.py", line 5, in <module>
    from sensor_msgs.msg import Imu
ImportError: No module named msg

All the "common_msgs" packages were installed to the same directory, so I checked what is the difference between "sensor_msgs" and "geometry_msgs" (the last one worked fine).

The "geometry_msgs" has a single directory in my installation directory ("dist-packages"):

-geometry_msgs/
--__init__.py
--__init__.pyc
--msg/

The "sensor_msgs" had 2 directories in "dist-packages":

-sensor_msgs/
--msg/
--srv/
-sensor_msgs-1.12.7-py2.7.egg/
--EGG-INFO
--sensor_msgs/
---__init__.py 
---__init__.pyc 
---point_cloud2.py 
---point_cloud2.pyc

Python only recognized the second directory (sensor_msgs-1.12.7-py2.7.egg), but this one didn't have any message files except the "point_cloud2".

I found a way to fix it for me: I removed the "catkin_python_setup()" line from "sensor_msgs/CMakeLists.txt" file and "<buildtool_depend condition="$ROS_PYTHON_VERSION..." lines from "sensor_msgs/package.xml" and then rebuilt it. I am not sure how and why, but this solved my issue. Maybe, this information will be useful for someone to fix it in the future.

After the fix, the "sensor_msgs" directory looks like this (and works fine):

-sensor_msgs/
--__init__.py 
--__init__.pyc
--msg/
--srv/

My environment:
ARM (32-bit)
Debian GNU/Linux 9
ROS Melodic
Python v2.7.13
sensor_msgs version: 1.12.7

Eugene

I was debating the idea of adding an 'acceleration' type message to complement twist, pose, wrench. This would be very helpful for some controller work where accelerations are passed around between several components.

I'm guessing that geometry_msgs naming conventions (Twist, Wrench) came out of the KDL classes? http://people.mech.kuleuven.be/~rsmits/kdl/api/html/annotated.html

KDL seems to lump both acceleration and velocity information using the Twist semantic (TwistVel and TwistAcc). What would be the preferable option:

1. Update the description of 'Twist' messages to include velocity AND acceleration
   or
2. Add Accel.msg, AccelStamped.msg, etc. to provide clear separation between the two types
   or
3. Do nothing at all

I am receiving the following error after running catkin_make

-- +++ processing catkin package: 'actionlib_msgs'
-- ==> add_subdirectory(common_msgs/actionlib_msgs)
-- actionlib_msgs: 3 messages, 0 services
CMake Error at common_msgs/actionlib_msgs/CMakeLists.txt:19 (catkin_install_python):
  Unknown CMake command "catkin_install_python".


-- Configuring incomplete, errors occurred!
See also "/home/pi/catkin_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/pi/catkin_ws/build/CMakeFiles/CMakeError.log".
Invoking "cmake" failed

I installed the package using the following command:

cd ~/catkin_ws/src/
git clone https://github.com/ros/common_msgs
cd ~/catkin_ws/

I am very new to ROS and have been trying to find this issue online to no avail. Any help would be greatly appreciated.

Background info:
Python 2.7
Ros Groovy
Raspberry Pi running Raspian GNU/Linux 8.0 (Jessie)

But with #27 fixed it's not guarenteed available.

See here:

Not a huge deal, since the contents are essentially the same (6 doubles) but I would expect to see a definition using geometry_msgs/Accel:

geometry_msgs/Accel[] accelerations

Based on this file https://github.com/ros/common_msgs/blob/indigo-devel/sensor_msgs/include/sensor_msgs/distortion_models.h, the supported distortion models are "plumb_bob" and "rational_polynomial"

The distortion models in two of our cameras use "Modified Brown-Conrady" and "Inverse Brown-Conrady".

• Are there any plans to support these distortion models too?
• If no, are we not supposed to create "sensor_msgs/CameraInfo" ROS messages for these unsupported distortion models?

Hi, I just installed ros, but can not found sensor_msgs::CameraInfo on kinetic Ubuntu 16.04.

error:

 error: ‘CameraInfo’ in namespace ‘sensor_msgs’ does not name a type
   void cbCameraInfo(const sensor_msgs::CameraInfo msg_info);
                                        ^
In file included from /opt/ros/kinetic/include/ros/serialization.h:37:0,
                 from /opt/ros/kinetic/include/ros/publisher.h:34,
                 from /opt/ros/kinetic/include/ros/node_handle.h:32,
                 from /opt/ros/kinetic/include/ros/ros.h:45,

How could I include that anyway?

I want to describe jerk in geometry_msgs.
However, there is an acceleration message, but there are no jerk message.
So, I want to add message for jerk.

Currently, all sensor messages have the stamp built in. This is the expected behavior. However, when the sensors drivers provided by OEM return data that's covering multiple messages, (and when using message filter is either not feasible or overkill) I felt the need for using Unstamped form of the message.

Basically, for new messages being proposed such as those in #101, can we have the following:

• AngularVelocityUnstamped.msg

geometry_msgs/Vector3 value
float64[9] covariance # Row major about x, y, z axes

• AngularVelocity.msg

Header header
AngularVelocityUnstamped angular_velocity

This allows combination of messages to be done for sensors.

• Some weird message

Header header

AngularVelocityUnstamped ang_vel
TemperatureUnstamped temp

As a followup, if we added code during generation, we can allow for explicit conversion (implicit might be bad for obv reasons) between messages which have a data or value field in them without having to specify the field such as

Int32 i32;
AngularVelocityUnstamped ang_vel;

// current
int val = i32.data;
double ang = ang_val.value;

// proposed
int val(i32);
double ang(ang_vel);

This might help in reducing the number of indirections required to refer to the data member in some places.

explicit operator T() const { return value; }
// OR
explicit operator T() const { return data; }

The sensor_msgs package depends on boost because boost::str() and boost::format() are called to format an error message in point_cloud_conversion.h:120, but...

• boost is not explicitly declared as a dependency (of type <run_depend> or <build_export_depend>?) in package.xml, only indirectly through message_runtime.

• point_cloud_conversion.h is lacking an include directive for <boost/format.hpp> and includes this header only indirectly via ros/time.h:

  . /opt/ros/indigo/include/sensor_msgs/point_cloud_conversion.h
  .. /opt/ros/indigo/include/sensor_msgs/PointCloud.h
  ... /opt/ros/indigo/include/ros/serialization.h
  .... /opt/ros/indigo/include/ros/time.h
  ..... /usr/include/boost/math/special_functions/round.hpp
  ...... /usr/include/boost/math/policies/error_handling.hpp
  ....... /usr/include/boost/format.hpp
  

• convertPointCloud2ToPointCloud() should return false after printing the message to stderr in line 120.

This is not directly related to those three issues, but we spent some time finding a problem while building sensor_msgs and dependents on a RedHat system with cmake 2.8.9, because sensor_msgs picked up and exported wrong Boost library paths in its generated cmake config if it was compiled without the -DBoost_NO_BOOST_CMAKE=ON argument (see http://stackoverflow.com/questions/9948375/cmake-find-package-succeeds-but-returns-wrong-path).

From #38

Targeting J-Turtle

Often the temperatures are also measured but cannot be put in the BatteryState message.

Nowadays, there seem to be lots of multiple-layer lidars on the market. I've noticed there's no datatype that would represent them as laserscans (of course, you can transform them into pointclouds right away, but you can lose some information during the transformation).

The result is that most lidar vendors create their own message types, which are, of course, incompatible. And then, it also means each lidar vendor provides his own version of raw data->pointcloud transformers, although there already is the standard (though single-layer) LaserScanToPointCloud tool provided by ROS.

I think it'd be nice to provide a common defeinition vendors could use to get to the same nice state where single-layered lidars are now in ROS.

However, I'm neither a lidar maker, nor do I feel I could persuade them to switch to a different scan message. Do you see any way to proceed?

E.g. Gazebo has its own multilayered scan definition, although a simplified one which doesn't account for the time it takes to capture the scan: https://bitbucket.org/osrf/gazebo/src/default/gazebo/msgs/laserscan.proto .

I will be using sensor TCS34725 and from it's python library I can see it provides the user with:

• RGB color data (0-255 values);
• color temperature (in K);
• illuminance (in lux).

The sensor only reads RGBC data, the last two are calculated values, so nothing I can't do on my own from a published RGB-type message. However, I have found that the only really officially supported message regarding color sensor data is the illuminance message, as there is an RGBA color message but it seems to be more geared towards a different kind of usage (because of the alpha).

I have previously worked a bit with colors and know about the multitude of standards that exist, so that might be a reason why this hasn't been implemented yet. Regardless, if we stay within the robotics applications, an RGB/sRGB definition could be enough, and would set a standard way to talk about RGB/sRGB colors.

Is this worth talking about as a standard or should I use my own message for my own use case?

Hi

First I read your "Guidelines for submitting to common_msgs" but still I think there is the need for some gerneric msgs I like to discuss.
The pkg should contain std_msg types with a header and as header array version at least for:
int8, uint8, int16, uint16, int32, uint32, int64, uint64, Float32, Float32 and string.
I think this would prevent a uncontrolled growth of msg types.

Geetings
Markus

e.g.

------------------------- #UInt64Stamped -------------------------
Header header
uint16 data
------------------------- #UInt64Array -------------------------
uint16[] data
------------------------- #UInt64StampedArray -------------------------
Header header
uint16[] data

most of the packages in common_msgs do not use genmsg in :
find_package(catkin REQUIRED COMPONENTS genmsg ...)

even though they use the macros from genmsg. This does not cause failures in a catki workspace with e.g. std_msgs (because we have a single global macro namespace), but causes failure when building common_msgs or packages thereof in an isolated workspace.

Plenty of similar bugs may exist in any number of catkin packages, unless all catkin packages get build in isolation, such errors will surface only randomly.

When building with -Wall Werror on the latest version of indigo I am hit with the following error during compilation:

/opt/ros/indigo/include/sensor_msgs/point_field_conversion.h:123:5: error: control may reach end of non-void function [-Werror,-Wreturn-type]
    }

Compiler:
clang 3.6

OS:
Ubuntu 14.04

This prevents my project from using -Wall -Werror.

I can make a patch but it is unclear to me how you would prefer the error condition be handled here.

Useful to include information about remaining time till full/empty

Is there a reason these aren't included?

More importantly, is there a reason why we shouldn't make these for ourselves and start using them in our API?

Is there an official place that they exist elsewhere?

I think we found a bug in geometry_msgs (branches indigo-devel and jade-devel):

The new message definition geometry_msgs/InertiaStamped.msg depends on the non-existent package telemanip_msgs.

This was introduced by this pull request #55

Can somebody confirm this issue?

Would it be possible to add an array message definition for PoseWithCovariance? This would be useful to publish history of poses with covariance in a single message, which is not currently possible.

The latest Hydro update broke action message generation using rosmake.

Steps to reproduce:

source /opt/ros/hydro/setup.zsh
cd katana_msgs
export ROS_PACKAGE_PATH=$(pwd):$ROS_PACKAGE_PATH
rosmake

This produces the following error:

  -- Action Files:JointMovement.action
  -- Generating Messages for ActionJointMovement.action
  CMake Error at /opt/ros/hydro/share/cpp_common/cmake/cpp_commonConfig.cmake:49 (debug_message):
    Unknown CMake command "debug_message".
  Call Stack (most recent call first):
    /opt/ros/hydro/share/message_runtime/cmake/message_runtimeConfig.cmake:177 (_pack_libraries_with_build_configuration)
    /opt/ros/hydro/share/actionlib_msgs/cmake/actionlib_msgsConfig.cmake:167 (find_package)
    /opt/ros/hydro/share/actionlib_msgs/cmake/actionbuild.cmake:30 (find_package)
    CMakeLists.txt:14 (genaction)

This happens for any package that contains an action definition.

Workaround:

Inserting

include(/opt/ros/hydro/share/catkin/cmake/debug_message.cmake)

into

/opt/ros/hydro/share/actionlib_msgs/cmake/actionbuild.cmake

"fixes" the problem.

I know this is probably not the correct place to report this, and that the error is somewhere else, but since the only thing to go with is actionbuild.cmake from this repo, I'm reporting this here.

I looked through the API Reviews; doesn't look like these have been formally discussed before. If there's interest, I can create an API review for either or both.

Encoder

Similar philosophy to the Range message—a single message which encapsulates the low-level information about an encoder: pulses per radian (fixed), present total pulses, present pulses/s.

It's ultimately expressing the same/similar information to that which ultimately ends up in an Odometry message, but at a lower level. Having Encoder messages published by drive bases with the appropriate transforms might allow for a standard Odometry publisher.

Electric

Measure of voltage with respect to ground, and current at a particular point. Suggested fields would be voltage_mean, voltage_std, current_mean, current_std, measurement_period.

An obvious outcome of having a common message for this type of thing would be the possibility of more standardized monitoring components—eg, a fuel tank node, something which flags on current spikes, etc.

Hello,

Starting with commit 5276dce all of our actionlib_msgs are now being installed into the wrong location.

The are now being installed into <install_space>/<devel_space>

Example:
Install space : /tmp/buildd/workspace/install
Devel space: /tmp/buildd/workspace/build/devel

Package: strategy_management_msgs

Actionlib msgs are now in : /tmp/buildd/workspace/install/share/strategy_management_msgs/tmp/buildd/workspace/build/devel/strategy_management_msgs/share/strategy_management_msgs/msg

All other messages are in their expected directory location under the install space.

Any help with this issue would be appreciated.

I wonder why the sensor_msgs don't include a message for bumpers, with header and a boolean (is_pressed).

In gazebo_msgs there's a ContactState.msg that might be used for this purpose, but it looks overcomplicated for a bumper that just has two states.

Since it's common to have bumpers in a robot, IMHO there should be a msg to represent them; indeed, there are even messages for Temperature and RelativeHumidity.

Hi

We enhanced the stage ros simulation to work with fiducials and I also wrote a ros package to detect visual markers (v4r_artoolkitplus, v4r_ellipses) in all this cases a common sensor message would be needed to represent a detected marker as pose with an id. In addition a second message is needed to represent the detection with a list of marker (pose+id), header min, max sensor range of the detection.

Marker.msg

# This expresses a marker/fiducial in a 3D space
uint32 id                    # id of the detected fiducial (0 if id could not be identified)
geometry_msgs/Pose pose      # pose of the detected marker/fiducial

MarkerDetection.msg

# This expresses a marker/fiducial detection
Header header                 # timestamp in the header is the acquisition time and frame

float32 distance_min          # distance minimum range value [m]
float32 distance_max          # distance maximum range value [m]
float32 distance_max_id       # distance maximum range value to detect id [m]

float32 angle_horizontal_min  # start horizontal angle of the detection [rad]
float32 angle_horizontal_max  # end horizontal angle of the detection [rad]
float32 angle_vertical_min    # start vertical angle of the detection [rad]
float32 angle_vertical_min    # end vertical angle of the detection [rad]

Marker[] markers              # detected markers

MarkerStamped.msg

# An marker with reference coordinate frame and timestamp
Header header
Marker marker

MarkerWithCovariance.msg

# This expresses a marker in free space with uncertainty.

Marker marker

# Row-major representation of the 6x6 covariance matrix
# The orientation parameters use a fixed-axis representation.
# In order, the parameters are:
# (x, y, z, rotation about X axis, rotation about Y axis, rotation about Z axis)
float64[36] covariance

MarkerWithCovarianceStamped.msg

# MarkerWithCovarianceStamped.msg
# This represents a marker with reference coordinate frame and timestamp and covariance matrix
Header header
MarkerWithCovariance marker

As cheap LIDARs use triangular method to mesure distance, and the laser beam is not center aligned, the angle is not accurate.
I suggest we add "x offset" to laser scan msg, so the gmapping_slam can get accurate reflection points.

laser beam
*
│
│
│
└─────(rotation center)

Does anynone have better ideas?

I am trying to read some ROS Bag messages (using my own parser), and I am having trouble understanding how arrays are interpreted:

In CameraInfo we have:

float64[] D
float64[9] K
float64[9] R

It appears to me that when an array has undefined size, it means the data in the file is preceded by an uint32 length, as it happens with D, and when a fixed size is specified, like K and R, the values are stored directly.

Then, Image has a uint8[] data; field, which states in the comment that it doesn't have a preceding length.

Does this also apply to the uint8[] data; of CompressedImage ?

What is the general rule to handle arrays when length is not defined in the msg? Is there a way to tell which ones need to read the length beforehand and which don't?

Bag: https://www.dropbox.com/s/tie8svln73ii3ii/imu.bag

Command: rostopic echo -b imu.bag -p /android/imu

Python version : 3.6.8
ROS: Kinetic, installed from source

I am trying to compile the common_msgs from source with python3.6.8 and i am getting the following error.
could you please let me know if you have solution for this. I see this is more like python issue. But want confirmation if somebody has faced similar issue.
Thank you!

dummy@dummy:~/catkin_sensor_msgs$ catkin build
-----------------------------------------------------------------------------
Profile:                     default
Extending:             [env] /home/dummy/ros_catkin_ws/install_isolated
Workspace:                   /home/dummy/catkin_sensor_msgs
-----------------------------------------------------------------------------
Build Space:        [exists] /home/dummy/catkin_sensor_msgs/build
Devel Space:        [exists] /home/dummy/catkin_sensor_msgs/devel
Install Space:     [missing] /home/dummy/catkin_sensor_msgs/install
Log Space:         [missing] /home/dummy/catkin_sensor_msgs/logs
Source Space:       [exists] /home/dummy/catkin_sensor_msgs/src
DESTDIR:            [unused] None
-----------------------------------------------------------------------------
Devel Space Layout:          linked
Install Space Layout:        merged
-----------------------------------------------------------------------------
Additional CMake Args:       None
Additional Make Args:        None
Additional catkin Make Args: None
Internal Make Job Server:    True
Cache Job Environments:      False
-----------------------------------------------------------------------------
Whitelisted Packages:        None
Blacklisted Packages:        None
-----------------------------------------------------------------------------
Workspace configuration appears valid.

NOTE: Forcing CMake to run for each package.
-----------------------------------------------------------------------------
[build] Found '10' packages in 0.0 seconds.                                                                                                   
Starting  >>> catkin_tools_prebuild                                                                                                           
Finished  <<< catkin_tools_prebuild                [ 1.0 seconds ]                                                                            
Starting  >>> actionlib_msgs                                                                                                                  
Starting  >>> diagnostic_msgs                                                                                                                 
Starting  >>> geometry_msgs                                                                                                                   
Finished  <<< diagnostic_msgs                      [ 2.4 seconds ]                                                                            
Finished  <<< actionlib_msgs                       [ 2.5 seconds ]                                                                            
Finished  <<< geometry_msgs                        [ 4.2 seconds ]                                                                            
Starting  >>> nav_msgs                                                                                                                        
Starting  >>> sensor_msgs                                                                                                                     
Starting  >>> shape_msgs                                                                                                                      
Starting  >>> trajectory_msgs                                                                                                                 
Starting  >>> visualization_msgs                                                                                                              
Finished  <<< shape_msgs                           [ 2.6 seconds ]                                                                            
Finished  <<< trajectory_msgs                      [ 2.9 seconds ]                                                                            
Finished  <<< nav_msgs                             [ 4.4 seconds ]                                                                            
Finished  <<< visualization_msgs                   [ 3.8 seconds ]                                                                            
______________________________________________________________________________________________________________________________________________
Errors     << sensor_msgs:install /home/dummy/catkin_sensor_msgs/logs/sensor_msgs/build.install.000.log                                 
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --install-layout not recognized
CMake Error at catkin_generated/safe_execute_install.cmake:4 (message):
  
  execute_process(/home/dummy/catkin_sensor_msgs/build/sensor_msgs/catkin_generated/python_distutils_install.sh)
  returned error code
Call Stack (most recent call first):
  cmake_install.cmake:132 (include)


make: *** [install] Error 1
cd /home/dummy/catkin_sensor_msgs/build/sensor_msgs; catkin build --get-env sensor_msgs | catkin env -si  /usr/bin/make install; cd -
..............................................................................................................................................
Failed     << sensor_msgs:install                  [ Exited with code 2 ]                                                                     
Failed    <<< sensor_msgs                          [ 5.6 seconds ]                                                                            
Abandoned <<< stereo_msgs                          [ Unrelated job failed ]                                                                   
[build] Summary: 8 of 10 packages succeeded.                                                                                                  
[build]   Ignored:   1 packages were skipped or are blacklisted.                                                                              
[build]   Warnings:  None.                                                                                                                    
[build]   Abandoned: 1 packages were abandoned.                                                                                               
[build]   Failed:    1 packages failed.                                                                                                       
[build] Runtime: 11.6 seconds total.                                                                                                          
[build] Note: Workspace packages have changed, please re-source setup files to use them.
Exception ignored in: <bound method BaseEventLoop.__del__ of <_UnixSelectorEventLoop running=False closed=True debug=False>>
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/trollius/base_events.py", line 395, in __del__
  File "/usr/local/lib/python3.6/site-packages/trollius/unix_events.py", line 65, in close
  File "/usr/local/lib/python3.6/site-packages/trollius/unix_events.py", line 166, in remove_signal_handler
  File "/usr/local/lib/python3.6/signal.py", line 47, in signal
TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object

Hi, I have a Raspberry Pi 3b+ with Raspbian stretch and I'm getting the error:

ERROR: No definition of [geometry] for OS [debian]

as described in ros/std_msgs#5 , I'd like to introduce new data type, StringArray.msg somewhere in common_msgs. Do you have any suggestion on which package to put this msg?

$ cat StringArray.msg
string[] strings

we're using this type of message, for example obtain speech recognition result candidates.

https://svn.code.sf.net/p/jsk-ros-pkg/code/trunk/jsk_smart_apps/jsk_gui_msgs/msg/VoiceMessage.msg

Package geometry_msgs has PoseArray, a list of Poses defined. This is the only Array version of otherwise single message instances, like PoseStamped, TransformStamped, ...

Would it make sense to also add a PoseStampedArray and/or TransformStampedArray?

I always get such error:
error: field points[] must be of type [trajectory_msgs/JointTrajectoryPoint]
I do not know the correct format of JointTrajectoryPoint, can anybody give me an example?

This type of message is documented as a MultiDOFJointTrajectory

I think we could have a similar message for Cartesian/Operational space trajectories.

Looks like the most recent one (1.12.5) was in 2016, and there have been a number of fixes that have gone in since. It'd be great to have a tag for that stuff:

http://repositories.ros.org/status_page/ros_melodic_default.html?q=common_msgs

Hi,
The underwater robotics community working with ROS is growing every day. Despite most of the sensors that we use are similar to other robotic domains (IMU, GPS, range, pressure, ...) there is a basic sensor, the Doppler Velocity Logger, that is not available in the sensor_msgs package. This sensor measures velocities wrt. the sea bottom and/or a mass of water. Additionally it can measure the range wrt. to the bottom, temperature, ...

Right now there are several public messages for this sensor.

• Some are based on one of the most popular DVL devices (Teledyne Explorer DVL): https://github.com/uji-ros-pkg/underwater_simulation/blob/kinetic-devel/underwater_sensor_msgs/msg/DVL.msg
• Others try to be more generic: https://github.com/uuvsimulator/uuv_simulator/blob/master/uuv_sensor_plugins/uuv_sensor_plugins_ros_msgs/msg/DVL.msg

I think people developing the uuv_simulator (@sebastianscherer, @musamarcusso), the auv_msgs package (@IgnacioCarlucho, @bmagyar) or many other people in the underwater community could be interested on having a standard message for the DVL in the sensor_msgs package.

How can we discuss about this topic?
Thank you!

I've been running experiments with the tabletop_object_detector and found that the segmentation crashed. Those detection/segmentation nodes are passing pointclouds by sensor_msgs::PointCloud, not PointCloud2.
The bug always comes when sensor_msgs::convertPointCloudToPointCloud2() is called. I captured the point clouds that are being pushed to the converter at that time.

I set up a node that reproduces the bug. The code is the following:
http://pastebin.com/j6PUF2G7

Bag file with the data that produces the error: (~10MB)
https://www.dropbox.com/s/4fwc0d7d8vihsq0/points_cut2.bag

I managed to fix it by adding 'volatile' to 'int offset' in the function.

It was missed in the catkinization. http://answers.ros.org/question/64836/common_msgs-package-missing-sensor_msgspoint_cloud2py-in-groovyprecise/

Would there be any interest in extending the NavSatStatus message to include a quality status? Right now it isn't easy to see what type of position quality you have.

Proposed extension:

# Navigation Satellite fix status for any Global Navigation Satellite System

# Whether to output an augmented fix is determined by both the fix
# type and the last time differential corrections were received.  A
# fix is valid when status >= STATUS_FIX.

int8 STATUS_NO_FIX =  -1        # unable to fix position
int8 STATUS_FIX =      0        # unaugmented fix
int8 STATUS_SBAS_FIX = 1        # with satellite-based augmentation
int8 STATUS_GBAS_FIX = 2        # with ground-based augmentation

int8 status

# Bits defining which Global Navigation Satellite System signals were
# used by the receiver.

uint16 SERVICE_GPS =     1
uint16 SERVICE_GLONASS = 2
uint16 SERVICE_COMPASS = 4      # includes BeiDou.
uint16 SERVICE_GALILEO = 8

uint16 service

# Define GPS quality from NMEA-183 GGA Standard

int8 STATUS_NOT_VALID =  0        # Fix not valid
int8 STATUS_FIX =        1        # GPS fix
int8 STATUS_DGPS_FIX =   2        # Differential GPS fix, OmniSTAR VBS
int8 STATUS_RTK_FIX =    4        #  Real-Time Kinematic, fixed integers
int8 STATUS_FLOAT_FIX =  5        # Real-Time Kinematic, float integers, OmniSTAR XP/HP or Location RTK

int8 quality

NMEA-183 GGA Sentence https://www.trimble.com/OEM_ReceiverHelp/V4.44/en/NMEA-0183messages_GGA.html

Hi!

At Terabee we are wondering if we could add RangeArray to sensor_msgs? Given the nature of our products that are possible to flexibly mount in various location of the robot this would make sense (it's easier to handle as you need to handle a single topic and a single message).

Here is what we currently use.

We also notice that there are some other organizations defining similar messages (e.g. bitcraze).

If you think this would be an useful addition we would happily create a pull request.

The Python library for writing point clouds has some weird bit-packing issues.

Consider writing this script for writing colors:

from sensor_msgs.point_cloud2 import create_cloud
from sensor_msgs.msg import PointField
import struct

fields = []
fields.append( PointField('rgb', 0, PointField.FLOAT32, 1) )

def pack_bytes(r,g,b,a):
    print 'original:', [b,g,r,a]
    x = (a << 24) + (r << 16) + (g << 8) + b
    a = struct.unpack('f', struct.pack('I', x))[0]

    points = [ (a, )]

    nc = create_cloud(None, fields, points)

    print 'packed  :', [ord(x) for x in nc.data]
    print


pack_bytes(120,0,0,0)
pack_bytes(120,0,0,255)

pack_bytes(130,0,0,0)
pack_bytes(130,0,0,255)

This outputs:

original: [0, 0, 120, 0]
packed  : [0, 0, 120, 0]

original: [0, 0, 120, 255]
packed  : [0, 0, 120, 255]

original: [0, 0, 130, 0]
packed  : [0, 0, 130, 0]

original: [0, 0, 130, 255]
packed  : [0, 0, 194, 255]

There is a bug where if red value is over 127 and the alpha value is 255, the output values do not match the input values.

I realize that the alpha is not necessarily supported, but I found it in a bag file (from a kinect I believe) and it was causing problems.

E.g.

All the sensor related messages have variance/covariance field: FluidPressure, Illuminance, Imu, MagneticField, NavSatFix, RelativeHumidity, Temperature; while Range lacks it.

Though rangefinders' datasheets often provide such information, and it can be quite useful for the consumers of rangefinder drivers.

I got this error from the following header:

common_msgs/sensor_msgs/include/sensor_msgs/image_encodings.h

To solve it I had to add #include<cstdlib>

The visualization_msgs/Marker should add a type for lists of arrows.
The message definition already has types for lists for spheres, cubes and lines. The types appear inconsistent since spheres and cubes exist as single and list version, but the line only exist as list version and the arrow and the cylinder only exist as single version. Having all basic shapes as single and list version would be more consistent.

The closest to ARROW_LIST is LINE_LIST, but the line does not visualise the direction, i.e. the start and end point. The line is also just visualised as 2D rectangle with the normal oriented towards the camera view.

By its name, the MultiDOFJointTrajectoryPoint should be encoding joint positions, velocities, and accelerations for an n-DOF manipulator. But it is using Cartesian space messages (Transform and Twist). This seems like it was a hack to get multi-DOF and can only go up to 6-DOF.

This message should probably not exist, MultiDOFJointTrajectory should accumulate JointTrajectory msgs along with the list of joint names, and there should be a CartesianTrajectory message, along with CartesianTrajectoryPoint, the latter having poses, twists, and wrenches.

I was playing around with a PCL application that needs an organized point cloud as input. However, using do_transform_point_cloud (from tf2_sensor_msgs) returns an unorganized point cloud.

After a quick investigation. it seems like create_cloud always returns a 1 by n cloud, but I'm not sure if it would be enough to simply pass in width / height arguments or if the point packing must be adapted.