ros / genmsg Goto Github PK
View Code? Open in Web Editor NEWStandalone Python library for generating ROS message and service data structures for various languages
Home Page: http://wiki.ros.org/genmsg
Standalone Python library for generating ROS message and service data structures for various languages
Home Page: http://wiki.ros.org/genmsg
introduced in commit 80c0d2a
missing '()' after 'endif' at line 89.
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?
trac 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
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 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.
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?
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.
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
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.
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})
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.
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.
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
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:
source /opt/ros/groovy/setup.bash
export ROS_PACKAGE_PATH=/path/to/wge100_camera:$ROS_PACKAGE_PATH
rosmake wge100_camera
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.
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.
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.
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 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.
I suggest that instead genmsg should if possible provide a CMake target that users can depend on generically. If changed, this also affects
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.
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.
Create a message package with two messages.
a1.msg:
int32 a1
a2.msg:
int32 a2
Run catkin_make. It will generate a1.h and a2.h.
In a1.msg add an field that is of type a2.
a1.msg:
int32 a1
a2 a2_msg
Run catkin_make. a1.h is regenerated correctly.
Add any field to a2.msg.
a2.msg:
int32 a2
float32 a2_float
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.
Instead of passing a list of message/service files allow the automatic globbing of these files.
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
Lines 250 to 251 in 7d8b6ce
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']
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.
See make output: https://gist.github.com/4120623
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.
This CMakeLists.txt
:
Results in this:
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.
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)
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.
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')
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?
Lines 131 to 132 in 7d8b6ce
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?
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
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.
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
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
Based on the question http://answers.ros.org/question/77261/using-cuda-with-catkin-cant-generate-messages/
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.
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:
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?
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?
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
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:
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).
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.
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).
AttributeError: module 'interpreter' has no attribute 'chat'
`
I got this when running:
import interpreter
interpreter.chat("""Example""") # Executes a single command
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.
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:
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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.