ros / genmsg Goto Github PK

In https://github.com/ros/genmsg/blob/indigo-devel/src/genmsg/template_tools.py#L39 you import em, which I believe is em.py from http://www.alcyone.com/software/empy/ and that is LGPL. Your package is marked as BSD (according to http://wiki.ros.org/genmsg).

1.) Please add a LICENSE file to the top of the repo to make this part of the repo.
2.) add em.py to a requirements.txt and list under DEPENDENCIES on (http://wiki.ros.org/genmsg)?

Figure out the license situation - can you use a different template engine?

Also right now this seems to be only used with c++?
https://github.com/ros/gencpp/blob/indigo-devel/scripts/msg.h.template
Can you confirm?

Hi,

I'm not sure if this is right place to ask question. I think it is convention to use CAPITIAL letter for constant name, but does it MUST be a capital letter?

I see following code in roslisp (/share/common-lisp/ros/actionlib_msgs/msg/GoalStatus.lisp) and I'm afraid it can not distinguish "PENDING" and "Pending"

(cl:defmethod roslisp-msg-protocol:symbol-codes ((msg-type (cl:eql '<GoalStatus>)))
    "Constants for message type '<GoalStatus>"
  '((:PENDING . 0)
    (:ACTIVE . 1)
    (:PREEMPTED . 2)
    (:SUCCEEDED . 3)
    (:ABORTED . 4)
    (:REJECTED . 5)
    (:PREEMPTING . 6)

http://wiki.ros.org/msg

The variable pkgname_CODE_GENERATION_TARGETS will be used by catkin_package() to expose target names for code generation to downstream projects (if not installed).

In cases where constants in messages are set to special floats, for example:

float32 a = NaN
float32 p = Inf
float32 n = -Inf 

The successfully generated Python script declare those as:

a = nan
p = inf
n = -inf

However, those causes NameError as nan, inf don't exist.

The following works in Python:

a = float('nan')
p = float('inf')
n = float('-inf')

Hello,

It seems that both em and empy build a package with the same name.

When I tried to install RosAria on a fresh install of Kinetic Kame, the following error occured in file "/opt/ros/kinetic/lib/python2.7/dist-packages/genmsg/template_tools.py", Line 76:

interpreter = em.Interpreter(output=ofile, globals=g, options=em.RAW_OPT:True,em.BUFFERED_OPT:True})
AttributeError: 'module' object has no attribute 'Interpreter

I solved this problem by simply uninstalling em, and installing empy:

pip uninstall em
pip install empy

May be someone should investigate the problem?

Currently, if a set of messages are defined such that they create a cycle in the message dependency graph, e.g.:

Message1.msg contains:
Message2 field1

and Message2.msg contains:
Message1 field2

Message generation results in an error that looks like:

File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 321, in load_msg_depends
  load_msg_depends(msg_context, depspec, search_path)
File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 310, in load_msg_depends
  depspec = msg_context.get_registered(resolved_type)
File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 434, in get_registered
  if self.is_registered(full_msg_type):
File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 423, in is_registered
  package, base_type = package_resource_name(full_msg_type)
File "/opt/ros/indigo/lib/python2.7/dist-packages/genmsg/names.py", line 104, in package_resource_name
  val = tuple(name.split(PRN_SEPARATOR))
RuntimeError: maximum recursion depth exceeded while calling a Python object
CMake Error at /opt/ros/indigo/share/catkin/cmake/safe_execute_process.cmake:11 (message):

execute_process(/home/user/catkin_ws/build/catkin_generated/env_cached.sh
"/usr/bin/python" "/usr/bin/empy" "--raw-errors" "-F"
"/home/user/catkin_ws/build/test_messages/cmake/test_messages-genmsg-context.py"
"-o"
"/home/user/catkin_ws/build/test_messages/cmake/test_messages-genmsg.cmake"
"/opt/ros/indigo/share/genmsg/cmake/pkg-genmsg.cmake.em") returned error
code 1
Call Stack (most recent call first):
/opt/ros/indigo/share/catkin/cmake/em_expand.cmake:25 (safe_execute_process)
/opt/ros/indigo/share/genmsg/cmake/genmsg-extras.cmake:303 (em_expand)
test_messages/CMakeLists.txt:28 (generate_messages)

Cycles in the dependency graph should be specifically detected and a meaningful error should be generated rather than relying on the recursion depth error.

I must be doing something wrong, or would such a bug go unnoticed from the beginning of rosmsg?

I have a custom message which works with all the CLI tools and C++ (rosbag play, roscpp pubsub, rosmsg show). I can even load it in python using from darpa_msgs.msg import LocalizationHypotheses. But I can't get it to work with rosbag python module.

$ python
>>> import rosbag
>>> b = rosbag.Bag("robot_data_0_TEAMBASE.bag", "r")
>>> msg = next(b.read_messages(topics=["/robot_data/X1/confirmed_hypotheses_batch"]))[1]
WARNING: For type [darpa_msgs/LocalizationHypotheses] stored md5sum [7da59d174d4c697d0571b3a6fc9fed73] has invalid message definition."
>>> import genpy
>>> import rosbag.bag
>>> old = rosbag.bag._get_message_type
>>> def tmp(info):
...   genpy.dynamic.generate_dynamic(info.datatype, info.msg_def)[info.datatype]
...   return old(info)
...
>>> rosbag.bag._get_message_type = tmp
>>> msg = next(b.read_messages(topics=["/robot_data/X1/confirmed_hypotheses_batch"]))[1]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/ros/melodic/lib/python2.7/dist-packages/rosbag/bag.py", line 2699, in read_messages
    yield self.seek_and_read_message_data_record((entry.chunk_pos, entry.offset), raw, return_connection_header)
  File "/opt/ros/melodic/lib/python2.7/dist-packages/rosbag/bag.py", line 2862, in seek_and_read_message_data_record
    msg_type = _get_message_type(connection_info)
  File "<stdin>", line 2, in tmp
  File "/opt/ros/melodic/lib/python2.7/dist-packages/genpy/dynamic.py", line 138, in generate_dynamic
    specs = {core_type: genmsg.msg_loader.load_msg_from_string(msg_context, core_msg, core_type)}
  File "/opt/ros/melodic/lib/python2.7/dist-packages/genmsg/msg_loader.py", line 269, in load_msg_from_string
    spec = MsgSpec(types, names, constants, text, full_name, package_name)
  File "/opt/ros/melodic/lib/python2.7/dist-packages/genmsg/msgs.py", line 251, in __init__
    raise InvalidMsgSpec("Duplicate field names in message: %s"%names)
genmsg.base.InvalidMsgSpec: Duplicate field names in message: ['header', 'seq', 'stamp', 'frame_id', 'hypotheses', 'id', 'active', 'merged_to', 'position', 'x', 'y', 'z', 'covariance', 'objectness', 'confirmed', 'class_probabilities', 'n_detections', 'last_detection_stamp', 'image', 'header', 'seq', 'stamp', 'frame_id', 'format', 'data']
>>>

And the message is:

$ rosmsg show darpa_msgs/LocalizationHypotheses
std_msgs/Header header
  uint32 seq
  time stamp
  string frame_id
darpa_msgs/LocalizationHypothesis[] hypotheses
  int32 id
  bool active
  int32 merged_to
  geometry_msgs/Point position
    float64 x
    float64 y
    float64 z
  float64[9] covariance
  float64 objectness
  bool confirmed
  float32[] class_probabilities
  int32 n_detections
  time last_detection_stamp
  sensor_msgs/CompressedImage image
    std_msgs/Header header
      uint32 seq
      time stamp
      string frame_id
    string format
    uint8[] data

Is it possible that all the names that are being checked are not "namespaced" by their relative path in the message definition? I.e., putting two Header fields in different parts of the message is treated invalid?

The exception is raised here

And the names reported by the exception contains the "non-namespaced" field names: ['header', 'seq', 'stamp', 'frame_id', 'hypotheses', 'id', 'active', 'merged_to', 'position', 'x', 'y', 'z', 'covariance', 'objectness', 'confirmed', 'class_probabilities', 'n_detections', 'last_detection_stamp', 'image', 'header', 'seq', 'stamp', 'frame_id', 'format', 'data']

icy@aspire-a315-33:~/hrwros_ws/src/hrwros/hrwros_week1$ rosrun hrwros_week1 sensor_info_publisher.py
Traceback (most recent call last):
File "/home/icy/hrwros_ws/src/hrwros/hrwros_week1/scripts/sensor_info_publisher.py", line 39, in
from hrwros_utilities.sim_sensor_data import distSensorData as getSensorData
ImportError: No module named hrwros_utilities.sim_sensor_data

THIS ERROR APPEARS WHEN I EXECUTE ROSRUN

If a Header is included in a .msg file, but is not the first type, then the _has_header flag is set to False.

This is on line 257 of msgs.py.

 self.header_present = self.types[0] == HEADER_FULL_NAME and self.names[0] == 'header'

It is not clear to me why it is requiring that it be the first entry.

Either this should be corrected or the documentation at http://wiki.ros.org/msg should be updated to specify that Header must be first.

Message generation currently allows a message that contains duplicate constants to succeed through generation. For example:

TestConstant.msg:

uint8 MY_CONSTANT = 0
uint8 MY_CONSTANT = 0

Would succeed and generate the following struct:

template <class ContainerAllocator>
struct TestConstant_
{
  typedef TestConstant_<ContainerAllocator> Type;
  TestConstant_() {}
  TestConstant_(const ContainerAllocator& _alloc) { (void)_alloc; }
  enum { MY_CONSTANT = 0u };
  enum { MY_CONSTANT = 0u };
  typedef boost::shared_ptr< ::test_messages::TestConstant_<ContainerAllocator> > Ptr;
  typedef boost::shared_ptr< ::test_messages::TestConstant_<ContainerAllocator> const> ConstPtr;
}; // struct TestConstant_

Which declares two enums named MY_CONSTANT. This will not compile and because of this it should be caught earlier in the process to alert users that they have an error.

Any constant that is defined more than once (even if it has the same value) should likely result in an error alerting the user that they're doing something wrong.

Similar steps as for # 16
To reproduce:

mkdir genmsg_ws
cd genmsg_ws/
mkdir src
cd src
git clone https://github.com/ros/catkin.git
git clone https://github.com/ros/genmsg.git
catkin_create_pkg foo message_generation roscpp rospy
cd foo
mkdir msg
cd msg
echo "Header header
float32 pressure # [C]
float32 temperature # [kPa]" > bar.msg
cd ..
rm CMakeLists.txt
echo "cmake_minimum_required(VERSION 2.8.3)
project(foo)
find_package(catkin REQUIRED COMPONENTS message_generation roscpp rospy)
add_message_files(
  FILES
  bar.msg
)
generate_messages(
  DEPENDENCIES
  std_msgs  # Or other packages containing msgs
)
catkin_package()" > CMakeLists.txt
cd ../..
. /opt/ros/groovy/setup.bash 
catkin_make

works, but should fail since std_msgs was not find_packaged, nor is part of package.xml

• Definition (Message_definition.h)
  • ROS serialization (Message_ros_serialization.h)
  • ...

trac data:

• Owner: dthomas
• Reporter: jfaust
• Reported at: Thu Mar 18 17:36:38 2010
• URL: https://code.ros.org/trac/ros/ticket/2544

Only causes problems with make -jN for N greater than 1.

Basically, packages which depend on message packages only depend on the library, not the generated headers, so they might get built before all headers are generated.

@wjwwood

See make output: https://gist.github.com/4120623

If you call generate_messages() before calling add_service_files(...), then the error you get is the following:

imu_drivers_catkin/src/microstrain_3dmgx2_imu/imu_node.cc:55:46: fatal error: microstrain_3dmgx2_imu/AddOffset.h: No such file or directory
compilation terminated.

There should be a warning if you call generate_messages() and have not added message or service files.

In this ROS answers thread, it was mentioned that the best way to discover .msg files in a catkin environment would be to augment genmsg so that it generates a .cmake configuration file which describes the .msg (and .srv) files that it processed.

http://answers.ros.org/question/64553/how-do-you-locate-message-source-files-based-on-a-package-name-in-catkin/?answer=64561#post-id-64561

@dirk-thomas

Probably the best way would be if every message package (after find_package()-ing) exposes a variable pointing to all available message files. That should be pretty easy to generate in genmsg using a CMake config extra files.

This is especially useful for systems like Orocos/RTT which process ROS messages into typekits for real-time data transport.

The message

std_msgs/Empty data

and

std_msgs/Empty[1000] data

has the same hash.

Because gentools.py code ignore arrays.

In my opinion it's ugly bug.

In http://wiki.ros.org/Names 1.2.1 it says that "There is at most one forward slash ('/')". It is not double-slash, right?

When using cmi for building a workspace the generated __init__.py files from the devel space are getting installed. This happens after the __init__.py file from the source package has been installed.

This has initially been reported in ros/dynamic_reconfigure#21.

The problem is that the pattern for installing all __init__.py files from the devel space except the one in the root of the package fails.

REGEX "/@(pkg_name)/.+/__init__.pyc?$"

The /@(pkg_name)/ part actually matches the folder structure used by cmi and therefore the file devel_isolated/@(pkg_name)/lib/python2.7/dist-packages/@(pkg_name)/__init__.py matches and gets installed.

genmsg(0.5.16), gencpp(0.6.5), the most recent version of these code generation tools was two years ago. I would like to ask what the update strategy of the community is, whether the new version will not be released in the future.

The current design of genmsg requires users to depend on the xyz_gencpp target to build c++ libraries against messages in the same package. This requires users to know about gencpp and causes an ugly reference to gencpp internals in userland CMakeLists.txt.

See:
ros/catkin_tutorials#4

I suggest that instead genmsg should if possible provide a CMake target that users can depend on generically. If changed, this also affects

ros-infrastructure/catkin_pkg#26

Hi everyone.

I want to be able to define custom messages with custom namespaces. For example. I want to define a message that I could reference in C++ by project_name::Movement::Generic. I thought this was a CMake issue, but in catkin's repository I learned it's a limitation of message generation.

I would like for a future version of ROS to use messages with custom namespaces, as I also learned that implementing this feature now would break current packages.

I didn't test, but I suppose the same holds for services and actions. Please consider this for the future.

Thanks in advance.

It's used in the cmake extras for example: https://github.com/ros/genmsg/blob/hydro-devel/cmake/genmsg-extras.cmake.em#L24

This fails due to clean up in ros/common_msgs#27 fixed there in ros/common_msgs#30

when run "sudo make install", result this:
...
...
-- Up-to-date: /usr/local/share/genmsg/cmake/genmsgConfig.cmake
-- Up-to-date: /usr/local/share/genmsg/cmake/genmsgConfig-version.cmake
-- Up-to-date: /usr/local/share/genmsg/package.xml
-- Up-to-date: /usr/local/share/genmsg/cmake/pkg-genmsg.cmake.em
-- Up-to-date: /usr/local/share/genmsg/cmake/pkg-genmsg.context.in
-- Up-to-date: /usr/local/share/genmsg/cmake/pkg-msg-extras.cmake.in
-- Up-to-date: /usr/local/share/genmsg/cmake/pkg-msg-paths.cmake.develspace.in
-- Up-to-date: /usr/local/share/genmsg/cmake/pkg-msg-paths.cmake.installspace.in

• cd /home/achilles/genmsg
• mkdir -p /usr/local/lib/python3/dist-packages
• /usr/bin/env PYTHONPATH=/usr/local/lib/python3/dist-packages:/home/achilles/genmsg/build/lib/python3/dist-packages: CATKIN_BINARY_DIR=/home/achilles/genmsg/build /home/achilles/miniconda3/bin/python /home/achilles/genmsg/setup.py build --build-base /home/achilles/genmsg/build install --install-layout=deb --prefix=/usr/local --install-scripts=/usr/local/bin
  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/achilles/genmsg/build/catkin_generated/python_distutils_install.sh)
returned error code
Call Stack (most recent call first):
cmake_install.cmake:156 (include)

Makefile:61: recipe for target 'install' failed
make: *** [install] Error 1

This CMakeLists.txt:

https://github.com/allenh1/p2os/blob/eff7ff1beb99331ddcbd9bb05bf90aabead9bf38/p2os_teleop/CMakeLists.txt#L11

Results in this:

http://answers.ros.org/question/68278/jenkins-build-issues-file-install-cannot-find-obj-x86_64-linux-gnu/

It should probably assert that some messages are set to be generated, rather than failing when it tries to install the resulting files which obviously don't exist.

It would be great if we can have flexibility to specify namespace for the generated message/service type. This helps not to break old recording after refactoring package structure and changing package name or separate it out to new package (This means name space changes).

I am currently working on a library that allows the sending and receiving of messages in C++ without knowing their types at compile time.
While reviewing the code that generates the message definition and md5 sum (which is very well written and easy to read btw) to replicate it in C++, I came across the load_srv_from_string function

def load_srv_from_string(msg_context, text, full_name):
    """
    Load :class:`SrvSpec` from the .srv file.
    
    :param msg_context: :class:`MsgContext` instance to load request/response messages into.
    :param text: .msg text , ``str``
    :param package_name: context to use for msg type name, i.e. the package name,
      or '' to use local naming convention. ``str``
    :returns: :class:`SrvSpec` instance
    :raises :exc:`InvalidMsgSpec` If syntax errors or other problems are detected in file
    """
    text_in  = StringIO()
    text_out = StringIO()
    accum = text_in
    for l in text.split('\n'):
        l = l.split(COMMENTCHAR)[0].strip() #strip comments        
        if l.startswith(IODELIM): #lenient, by request
            accum = text_out
        else:
            accum.write(l+'\n')

    # create separate MsgSpec objects for each half of file
    msg_in = load_msg_from_string(msg_context, text_in.getvalue(), '%sRequest'%(full_name))
    msg_out = load_msg_from_string(msg_context, text_out.getvalue(), '%sResponse'%(full_name))
    return SrvSpec(msg_in, msg_out, text, full_name)

I haven't tested it which is why I said possibly in the title but wouldn't the comment stripping result in the incorrect removal of parts of valid constant definitions such as

string EXAMPLE="#comments" are ignored, and leading and trailing whitespace removed

taken from the msg wiki.

Hi!

When using genmsg / genpy to generate messages, the path of the host is leaked into the python cache modules. For example, in the official deployed ubunut packages, it is: for /opt/ros/noetic/lib/python3/dist-packages/std_msgs/__pycache__/__init__.cpython-38.pyc:

/tmp/binarydeb/ros-noetic-std-msgs-0.5.13/obj-x86_64-linux-gnu/devel/lib/python3/dist-packages/std_msgs/__init__.py

but it should be

/opt/ros/noetic/lib/python3/dist-packages/std_msgs/__init__.py

This is unwanted behavior. From the Docs, this path is used for

This [path] will appear in compilation time tracebacks, and is also compiled in to the byte-code file, where it will be used in tracebacks and other messages in cases where the source file does not exist at the time the byte-code file is executed.

Hence, the impact is very low, but still, it is an error

I'm working on PX4, which used genmsg for code generation. Now the ask has come up to generate docs for .msg files, and I see ROS uses http://wiki.ros.org/rosdoc_lite, which parses the files independently, w/o any structure for metadata (comments in particular).
This has obviously some drawbacks:

• It's very limited in how you can render docs
• Fields/msgs are not required to be documented at all
• Missing mechanism for additional metadata (e.g. minimum value for a field)

I'm suggesting to bring more structure to comments and parse them with genmsg, which then can be used to generate docs as well (single parser for all use-cases).
I have not gone into the details, but I imagine something like this:

# topic description
# @namespace xy

# field description
# @min min-value
# @ignored-value NaN
float x

float y # existing single-line field+comment is allowed as well

The tags are then parsed generically (no tag implies @comment tag), which then gets added as a dict to genmsg.MsgSpec and genmsg.Field, so they can be used in a template.
This should fit into the existing .msg file format structure.

Is there interest in extending files into that direction, and if so, are there any specific requirements you'd like to see?

@dirk-thomas @tfoote

add_action_files() is always using globbing, even when FILES are specified.
This also effects add_service_files() as well as add_message_files().

If you compile and install a package that contains python source code and messages the <package_name>/__init__.py file from the devel space gets installed into the install space overwriting the previously installed __init__.py from the source.

You can recreate this problem by building dynamic_reconfigure with catkin_make_isolated. The install_isolated/lib/python2.7/dist-packages/dynamic_reconfigure/__init__.py file is the one from devel_isolated/dynamic_reconfigure/lib/python2.7/dist-packages/dynamic_reconfigure/__init__.py.

I believe it is due to the install regex rule for installing __init__.py files from subdirectories. I assume this rule is matching <pkg_name>/./__init__.py

 install(
 DIRECTORY ${CATKIN_DEVEL_PREFIX}/${@(l)_INSTALL_DIR}/@pkg_name
 DESTINATION ${@(l)_INSTALL_DIR}
 FILES_MATCHING
 REGEX "${CATKIN_DEVEL_PREFIX}/${@(l)_INSTALL_DIR}/@(pkg_name)/.+/__init__.pyc?$"
 )

Strangely, this does not happen with catkin_make, I don't understand why its different.

Same behaviour using cmake version 2.8.12.2 and 2.8.7

We came across the following effect: For certain message definitions which differ the md5-sums are equal! I created a short example here: airballking/ros_test_pkgs@f2d3daf

Basically, I have a message definition md5_generation_issue/Test.msg which looks like this:

std_msgs/Int32 field
# std_msgs/Int32[] field
# std_msgs/Int32[1] field
# std_msgs/Int32[124] field

No matter which of the lines is uncommented (as long as it is only one), the md5-sum will always be 8b31b5679e76c808441b573f78ce35d1.

Is this a bug or a feature?

While trying to debug wge100_camera (https://github.com/ros-drivers/wge100_driver/tree/master/wge100_camera) locally I run into this error:

∫ make
mkdir -p bin
cd build && cmake -Wdev -DCMAKE_TOOLCHAIN_FILE=/opt/ros/groovy/share/ros/core/rosbuild/rostoolchain.cmake  ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found PythonInterp: /usr/bin/python (found version "2.7.3")
[rosbuild] Building package wge100_camera
[rosbuild] Cached build flags older than manifests; calling rospack to get flags
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking for include files CMAKE_HAVE_PTHREAD_H - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE 
-- Found gtest sources under '/usr/src/gtest': gtests will be built
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/wge100_driver/wge100_camera/build
cd build && make 
make[1]: Entering directory `/tmp/wge100_driver/wge100_camera/build'
make[2]: Entering directory `/tmp/wge100_driver/wge100_camera/build'
make[3]: Entering directory `/tmp/wge100_driver/wge100_camera/build'
Scanning dependencies of target rospack_gensrv
make[3]: Leaving directory `/tmp/wge100_driver/wge100_camera/build'
[  0%] Built target rospack_gensrv
make[3]: Entering directory `/tmp/wge100_driver/wge100_camera/build'
Scanning dependencies of target rospack_gensrv_all
make[3]: Leaving directory `/tmp/wge100_driver/wge100_camera/build'
[  0%] Built target rospack_gensrv_all
make[3]: Entering directory `/tmp/wge100_driver/wge100_camera/build'
Scanning dependencies of target rospack_genmsg_libexe
make[3]: Leaving directory `/tmp/wge100_driver/wge100_camera/build'
[  0%] Built target rospack_genmsg_libexe
make[3]: Entering directory `/tmp/wge100_driver/wge100_camera/build'
Scanning dependencies of target rosbuild_precompile
make[3]: Leaving directory `/tmp/wge100_driver/wge100_camera/build'
[  0%] Built target rosbuild_precompile
make[3]: Entering directory `/tmp/wge100_driver/wge100_camera/build'
Scanning dependencies of target wge100camera
make[3]: Leaving directory `/tmp/wge100_driver/wge100_camera/build'
make[3]: Entering directory `/tmp/wge100_driver/wge100_camera/build'
[  6%] Building C object src/wge100lib/CMakeFiles/wge100camera.dir/host_netutil.c.o
[ 12%] Building C object src/wge100lib/CMakeFiles/wge100camera.dir/list.c.o
/tmp/wge100_driver/wge100_camera/src/wge100lib/list.c: In function ‘wge100CamListDelAll’:
/tmp/wge100_driver/wge100_camera/src/wge100lib/list.c:192:6: warning: variable ‘count’ set but not used [-Wunused-but-set-variable]
[ 18%] Building C object src/wge100lib/CMakeFiles/wge100camera.dir/wge100lib.c.o
/tmp/wge100_driver/wge100_camera/src/wge100lib/wge100lib.c: In function ‘wge100ReliableFlashWrite’:
/tmp/wge100_driver/wge100_camera/src/wge100lib/wge100lib.c:1018:7: warning: variable ‘first_read’ set but not used [-Wunused-but-set-variable]
[ 25%] Building CXX object src/wge100lib/CMakeFiles/wge100camera.dir/mt9v.cpp.o
Linking CXX shared library ../../../lib/libwge100camera.so
make[3]: Leaving directory `/tmp/wge100_driver/wge100_camera/build'
[ 25%] Built target wge100camera
make[3]: Entering directory `/tmp/wge100_driver/wge100_camera/build'
Scanning dependencies of target wge100_camera_node
make[3]: Leaving directory `/tmp/wge100_driver/wge100_camera/build'
make[3]: Entering directory `/tmp/wge100_driver/wge100_camera/build'
[ 31%] Building CXX object src/nodes/CMakeFiles/wge100_camera_node.dir/wge100_camera_node.cpp.o
/tmp/wge100_driver/wge100_camera/src/nodes/wge100_camera_node.cpp:57:39: fatal error: wge100_camera/BoardConfig.h: No such file or directory
compilation terminated.
make[3]: *** [src/nodes/CMakeFiles/wge100_camera_node.dir/wge100_camera_node.cpp.o] Error 1
make[3]: Leaving directory `/tmp/wge100_driver/wge100_camera/build'
make[2]: *** [src/nodes/CMakeFiles/wge100_camera_node.dir/all] Error 2
make[2]: Leaving directory `/tmp/wge100_driver/wge100_camera/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/wge100_driver/wge100_camera/build'
make: *** [all] Error 2

There is a BoardConfig.srv file in the srv directory and there is a gensrv() call in the cmake. After running make, the srv_gen folder contains:

∫ ls srv_gen/
generated

In fuerte there is a cpp and lisp folder in there and it finds the header.

I am building against ros-groovy debs from shadow-fixed:

∫ dpkg -l | grep genmsg
ii  ros-fuerte-genmsg                        0.3.10-0precise-20120908-1622-+0000     Willow Garage low level build system macros and infrastructure
ii  ros-groovy-genmsg                        0.4.10-0precise-20120930-2328-+0000     Standalone Python library for generating ROS message and service data structures for various languages.

To reproduce:

1. Install groovy dependencies for wge100_camera
2. source /opt/ros/groovy/setup.bash
3. export ROS_PACKAGE_PATH=/path/to/wge100_camera:$ROS_PACKAGE_PATH
4. rosmake wge100_camera

To reproduce:

mkdir genmsg_ws
cd genmsg_ws/
mkdir src
cd src
git clone https://github.com/ros/catkin.git
git clone https://github.com/ros/genmsg.git
catkin_create_pkg foo message_generation roscpp rospy
cd foo
mkdir msg
cd msg
echo "Header header
float32 pressure # [C]
float32 temperature # [kPa]" > bar.msg
cd ..
rm CMakeLists.txt
echo "cmake_minimum_required(VERSION 2.8.3)
project(foo)
find_package(catkin REQUIRED COMPONENTS message_generation roscpp rospy)
add_message_files(
  FILES
  foo1.msg
  foo2.msg
  foo3.msg
)
generate_messages(
  DEPENDENCIES
  std_msgs  # Or other packages containing msgs
)
catkin_package()" > CMakeLists.txt
cd ../..
. /opt/ros/groovy/setup.bash 
catkin_make

yields

-- catkin 0.5.62
-- BUILD_SHARED_LIBS is on
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ~~  traversing packages in topological order:
-- ~~  - foo
-- ~~  - genmsg
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
[ 25%] [ 75%] [ 75%] Generating Python from MSG foo/bar
Generating Lisp code from foo/bar.msg
Generating C++ code from foo/bar.msg

should fail due to missing foo1.msg, foo2.msg, foo3.msg

Even in large projects with a lot of message definitions getting compiled, it would be nice if only messages get re-generated which have changed since the last generation.

Would it be possible to add this feature?

Here's a mention of bar_cpp:

https://github.com/ros/genmsg/blame/914058a5d3257bd9b2d1d49cb400111effabf875/doc/usermacros.rst#L41

Does it have anything to do with bar_gencpp?

https://github.com/ros/genmsg/blame/914058a5d3257bd9b2d1d49cb400111effabf875/doc/usermacros.rst#L39

Is one correct and the other incorrect? If so, which one is correct?

How many languages are supported as targets? Is there a list of these somewhere?

Pretty sure this is a repeat of issue #10.

My package works fine in devel space, when I go to install it, I get this:

$ catkin_make install  | grep __init__
Compiling /home/mikepurvis/husky_ws/devel/lib/python2.7/dist-packages/clearpath_base/__init__.py ...
Compiling /home/mikepurvis/husky_ws/devel/lib/python2.7/dist-packages/clearpath_base/msg/__init__.py ...
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/msg/__init__.pyc
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/msg/__init__.py

The __init__.py file in the package root get compiled, but it never gets installed.

On a hunch, I finally removed catkin_python_setup(), and then it does the right thing and installs the __init__.py file:

$ catkin_make install  | grep __init__
Compiling /home/mikepurvis/husky_ws/devel/lib/python2.7/dist-packages/clearpath_base/__init__.py ...
Compiling /home/mikepurvis/husky_ws/devel/lib/python2.7/dist-packages/clearpath_base/msg/__init__.py ...
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/__init__.pyc
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/__init__.py
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/msg/__init__.pyc
-- Installing: /home/mikepurvis/husky_ws/install/lib/python2.7/dist-packages/clearpath_base/msg/__init__.py

I know this is not an ideally-named package (or API design), but it's this way to maintain consistency with some historical decisions. The package source is here:

https://github.com/clearpathrobotics/clearpath_base

For now, I'm going to just work around this by manually installing the file, but it was a pretty nasty bug to figure out.

For interested parties, here's the workaround:

install(FILES ${CATKIN_DEVEL_PREFIX}/${CATKIN_PACKAGE_PYTHON_DESTINATION}/__init__.py
  DESTINATION ${CATKIN_PACKAGE_PYTHON_DESTINATION})

Maybe this is incredibly OCD of me, but according to the C++ standard [17.4.3.1.2]: "Each name that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use."

Not that I think it would ever happen in practice, but a C++ compiler would be within its rights to reject names like "__mutex" or "__getDataType".

trac data:

• Owner: mquigley
• Reporter: mihelich
• Reported at: Wed Jun 24 19:27:21 2009
• URL: https://code.ros.org/trac/ros/ticket/1298

AttributeError: module 'interpreter' has no attribute 'chat'
`
I got this when running:

import interpreter
interpreter.chat("""Example""") # Executes a single command

I think I said that right in the title.

Basically there is a case when the message generation is not rerun even when it should be. The problem is the list of .msg dependencies is generated during the cmake configure step and if you add a new field to a .msg file that is another message type that dependency list is never updated (until you rerun the cmake step).

You can reproduce the problem as follows.

1. Create a message package with two messages.

   a1.msg:

    int32 a1
   

   a2.msg:

    int32 a2
   

2. Run catkin_make. It will generate a1.h and a2.h.

3. In a1.msg add an field that is of type a2.

   a1.msg:

    int32 a1
    a2 a2_msg
   

4. Run catkin_make. a1.h is regenerated correctly.

5. Add any field to a2.msg.

   a2.msg:

    int32 a2
    float32 a2_float
   

6. Run catkin_make. a2.h is regenerated correctly. However a1.h is not. You can look at the "Definition" in a1.h and see it is missing the new field "a2_float". The md5sum is also wrong. If you delete the build directory and do a clean build the md5sum for a1 is now different.

This is pretty simple to implement, so I did.

NOTE: see also #2723

The attached msg_gen.py was modified from the Ubuntu 9.04 "latest" release.

The test file is not very formal, it just exercises the new API and prints to the console.

trac data:

• Owner: dthomas
• Reporter: baxelrod
• Reported at: Tue Apr 26 10:32:20 2011
• URL: https://code.ros.org/trac/ros/ticket/3469

Is there way to achieve this?
I have some ROS messages which are migrated to other package and deprecated.

I have a plan to add this feature to genpy and gencpp, to show deprecation warning on being included in a node.

While implementing a new message generator for a language which needs multiple files generated per message, I get the following traceback when my generator script is invoked:

Traceback (most recent call last):
  File "/home/user/ros/msg_gen_ws/src/gentxt/scripts/genmsg_txt.py", line 23, in <module>
    {})
  File "/home/user/ros/msg_gen_ws/src/genmsg/src/genmsg/template_tools.py", line 206, in generate_from_command_line_options
    generate_from_file(argv[1], options.package, options.outdir, options.emdir, options.includepath, msg_template_dict, srv_template_dict)
  File "/home/user/ros/msg_gen_ws/src/genmsg/src/genmsg/template_tools.py", line 147, in generate_from_file
    _generate_msg_from_file(input_file, output_dir, template_dir, search_path, package_name, msg_template_dict)
  File "/home/user/ros/msg_gen_ws/src/genmsg/src/genmsg/template_tools.py", line 92, in _generate_msg_from_file
    search_path)
  File "/home/user/ros/msg_gen_ws/src/genmsg/src/genmsg/template_tools.py", line 70, in _generate_from_spec
    interpreter = em.Interpreter(output=ofile, globals=g, options={em.RAW_OPT:True,em.BUFFERED_OPT:True})
  File "/usr/lib/pymodules/python2.7/em.py", line 2054, in __init__
    self.fix()
  File "/usr/lib/pymodules/python2.7/em.py", line 2091, in fix
    raise Error, "interpreter globals collision"
em.Error: interpreter globals collision

Contents of language specific generator wrapper script:

msg_template_map = { 'msg.a.template' : '@[email protected]', 'msg.b.template': '@[email protected]', 'msg.template': '@[email protected]' }
srv_template_map = {}

if __name__ == "__main__":
    genmsg.template_tools.generate_from_command_line_options(sys.argv, msg_template_map, srv_template_map)

Playing around a bit I noticed that completely empty templates let the generator run to completion (producing just empty files, obviously).

I'm not too familiar with empy internals, but it looks like the interpreter is doing something to the dictionary (g) which causes some empy internal test to fail when a second interpreter is passed the dictionary, leading to the exception. Moving the dictionary initialisation inside the for loop that iterates over the template_map lets message generation successfully complete, but I'm not sure that is actually a solution.

Instead of passing a list of message/service files allow the automatic globbing of these files.

If a package A generates messages which depend only on package B it should not need to know about B's dependencies to other message packages. Currently A has to specify all recursive message dependencies for generate_messages(DEPENDENCIES ...).

All other parts in CMake (find_package(), catkin_package()) already provide that so generate_messages() should be the same.

If the correct dependencies are not specified in generate_messages macro the genmsg will spit out a confusing python error. This should give a usefull error like:
"actionlib_msgs not found when generating for actionlib. Did you forget to specify actionlib_msgs in generate_messages() DEPENDENCIES" or something similar....

The current error message is:

--- Error parsing token: @{
import sys, genmsg, os
genmsg.base.log_verbose('GENMSG_VERBOSE' in os.environ)
# put this path at the beginning
sys.path.insert(0, genmsg_python_path)
import genmsg.deps

msg_deps = {}
for m in messages:
  msg_deps[m] = genmsg.deps.find_msg_dependencies(pkg_name, m, dep_search_paths)

srv_deps = {}
for s in services:
  srv_deps[s] = genmsg.deps.find_srv_dependencies(pkg_name, s, dep_search_paths)

}
    if __name__ == '__main__': main()
  File "/usr/bin/empy", line 3290, in main
    invoke(sys.argv[1:])
  File "/usr/bin/empy", line 3273, in invoke
    interpreter.wrap(interpreter.file, (file, name))
  File "/usr/bin/empy", line 2273, in wrap
    self.fail(e)
  File "/usr/bin/empy", line 2264, in wrap
    apply(callable, args)
  File "/usr/bin/empy", line 2337, in file
    self.safe(scanner, done, locals)
  File "/usr/bin/empy", line 2379, in safe
    self.parse(scanner, locals)
  File "/usr/bin/empy", line 2400, in parse
    token.run(self, locals)
  File "/usr/bin/empy", line 1410, in run
    interpreter.execute(self.code, locals)
  File "/usr/bin/empy", line 2580, in execute
    exec statements in self.globals
  File "<string>", line 10, in <module>
  File "/home/local/catkin_build2/build/lib/genmsg/deps.py", line 17, in find_msg_dependencies
    genmsg.msg_loader.load_depends(msg_context, spec, search_paths)
  File "/home/local/catkin_build2/build/lib/genmsg/msg_loader.py", line 343, in load_depends
    return load_msg_depends(msg_context, spec, msg_search_path)
  File "/home/local/catkin_build2/build/lib/genmsg/msg_loader.py", line 320, in load_msg_depends
    load_msg_depends(msg_context, depspec, search_path)
  File "/home/local/catkin_build2/build/lib/genmsg/msg_loader.py", line 312, in load_msg_depends
    depspec = load_msg_by_type(msg_context, resolved_type, search_path)
  File "/home/local/catkin_build2/build/lib/genmsg/msg_loader.py", line 118, in load_msg_by_type
    file_path = get_msg_file(package_name, base_type, search_path)
  File "/home/local/catkin_build2/build/lib/genmsg/msg_loader.py", line 78, in get_msg_file
    % (base_type, package, search_path))
genmsg.msg_loader.MsgNotFound: Cannot locate message [GoalID]: unknown package [actionlib_msgs] on search path [{'actionlib': '/home/local/catkin_build2/build/actionlib/actions_gen', 'std_msgs': '/home/local/catkin_build2/std_msgs/msg'}]
CMake Error at catkin/cmake/safe_execute_process.cmake:13 (message):
  Error executing process with arguments COMMAND
  /home/local/catkin_build2/build/env.sh /usr/bin/empy --raw-errors -F
  /home/local/catkin_build2/catkin/cmake/empy_util.py -F
  /home/local/catkin_build2/build/actionlib/cmake/actionlib-genmsg-context.py
  -F /home/local/catkin_build2/build/catkin/catkin-context.py -o
  /home/local/catkin_build2/build/actionlib/cmake/actionlib-genmsg.cmake
  /home/local/catkin_build2/genmsg/cmake/pkg-genmsg.cmake.em
Call Stack (most recent call first):
  catkin/cmake/em_expand.cmake:14 (safe_execute_process)
  build/cmake/genmsg/genmsg-extras.cmake:101 (em_expand)
  actionlib/CMakeLists.txt:28 (generate_messages)

introduced in commit 80c0d2a
missing '()' after 'endif' at line 89.

When building the base stacks with catkin/groovy/OS X 10.7.x I get:

∫ make
[  0%] Building CXX object rospack/CMakeFiles/rospack.dir/src/rospack.cpp.o
[  0%] Building CXX object rospack/CMakeFiles/rospack.dir/src/rospack_backcompat.cpp.o
[  0%] Building CXX object rospack/CMakeFiles/rospack.dir/src/utils.cpp.o
[  1%] Building CXX object rospack/CMakeFiles/rospack.dir/src/rospack_cmdline.cpp.o
[  1%] Building CXX object rospack/CMakeFiles/rospack.dir/tinyxml-2.5.3/tinyxml.cpp.o
[  1%] Building CXX object rospack/CMakeFiles/rospack.dir/tinyxml-2.5.3/tinyxmlparser.cpp.o
[  1%] Building CXX object rospack/CMakeFiles/rospack.dir/tinyxml-2.5.3/tinyxmlerror.cpp.o
Linking CXX shared library ../buildspace/lib/librospack.dylib
[  1%] Built target rospack
[  1%] Building CXX object rospack/CMakeFiles/rospackexe.dir/src/rospack_main.cpp.o
Linking CXX executable ../buildspace/bin/rospack
[  1%] Built target rospackexe
[  1%] Building CXX object rospack/CMakeFiles/rosstackexe.dir/src/rosstack_main.cpp.o
Linking CXX executable ../buildspace/bin/rosstack
[  1%] Built target rosstackexe
[  1%] Building CXX object ros/core/roslib/CMakeFiles/roslib.dir/src/package.cpp.o
Linking CXX shared library ../../../buildspace/lib/libroslib.dylib
[  1%] Built target roslib
[  1%] Building CXX object roscpp_core/cpp_common/CMakeFiles/cpp_common.dir/src/debug.cpp.o
Linking CXX shared library ../../buildspace/lib/libcpp_common.dylib
[  1%] Built target cpp_common
[  1%] Building CXX object roscpp_core/rostime/CMakeFiles/rostime.dir/src/time.cpp.o
[  1%] Building CXX object roscpp_core/rostime/CMakeFiles/rostime.dir/src/rate.cpp.o
[  1%] Building CXX object roscpp_core/rostime/CMakeFiles/rostime.dir/src/duration.cpp.o
Linking CXX shared library ../../buildspace/lib/librostime.dylib
[  1%] Built target rostime
[  1%] Building CXX object roscpp_core/roscpp_serialization/CMakeFiles/roscpp_serialization.dir/src/serialization.cpp.o
Linking CXX shared library ../../buildspace/lib/libroscpp_serialization.dylib
[  1%] Built target roscpp_serialization
[  1%] Generating C++ code from std_msgs/Bool.msg
[  1%] Generating C++ code from std_msgs/Byte.msg
[  1%] Generating C++ code from std_msgs/ByteMultiArray.msg


....


Scanning dependencies of target rosgraph_msgs_genpy
[ 37%] Generating Python from MSG rosgraph_msgs/Clock
[ 37%] Generating Python from MSG rosgraph_msgs/Log
[ 37%] Generating Python msg __init__.py for rosgraph_msgs
[ 37%] Built target rosgraph_msgs_genpy
[ 37%] Generating C++ code from std_srvs/Empty.srv
[ 37%] Built target std_srvs_gencpp
[ 37%] Generating Lisp code from std_srvs/Empty.srv
Traceback (most recent call last):
  File "/Users/william/devel/groovy/base/install/lib/python2.7/site-packages/genlisp-0.4.0-py2.7.egg/genlisp/genlisp_main.py", line 35, in genmain
    search_path = genmsg.command_line.includepath_to_dict(options.includepath)
  File "/Users/william/devel/groovy/base/install/lib/python2.7/site-packages/genmsg/command_line.py", line 35, in includepath_to_dict
    for path in includepath:
TypeError: 'NoneType' object is not iterable
ERROR:  'NoneType' object is not iterable
make[2]: *** [buildspace/share/common-lisp/ros/std_srvs/srv/Empty.lisp] Error 3
make[1]: *** [ros_comm/messages/std_srvs/CMakeFiles/std_srvs_genlisp.dir/all] Error 2
make: *** [all] Error 2

Not sure what brings this about, it looks like genlisp_main.py is getting called without the includepath command line option being set. I don't know if this just needs to check for None and return a default value or if the real problem is that the includepath command line option is not getting set.

This problem does occur with plain old make as well.

Based on the question http://answers.ros.org/question/77261/using-cuda-with-catkin-cant-generate-messages/

If catkin_python_setup() is used in a CMakeLists.txt file, genmsg's cmake code will avoid installing generated python message code.

The "tf" package does exactly this, because it has both message definitions and python code which needs to be installed. I have worked around it with some hand-coded install() calls in the CMakeLists.txt file, but it surprises me that this does not just do the right thing automatically.