ros / gencpp Goto Github PK

I made my own msg file by using catkin_make. But my IDE shows an error after include new_msg.h.

In file included from sketch/example_header.h:8:0,
from /home/zeta/Arduino/my_project/my_project.ino:23:
/home/zeta/Arduino/libraries/ros_lib/my_msg/new_msg.h:9:10: fatal error: string: No such file or directory
#include

https://github.com/ros/gencpp/blob/indigo-devel/scripts/msg.h.template#L17

The BSD license still attributes copyright to Willow Garage for auto generated message files. Should this (can this) be changed?

when using custom message with big structure, we may reach the windows compilator limit of 65535 character for a string.

This happens in msg creation when building the comment string in escape_message_definition function.

proposed patch is to break when 64000 size limit is reached 👍
def escape_message_definition(definition):
lines = definition.splitlines()
if not lines:
lines.append('')
s = StringIO()
count = 0
for line in lines:
line = _escape_string(line)
# individual string literals cannot be too long; need to utilize string concatenation for long strings
# https://docs.microsoft.com/en-us/cpp/c-language/maximum-string-length?view=vs-2017
s.write('"%s\n"\n' % (line))
#patch to exit when line total greater than 64000 due to windows compil limitation
count = count + len(line) + 6
if count > 64000:
break
val = s.getvalue()
s.close()
return val

In action_client.h (on lines 217 and 221) both goal_pub_ and cancel_pub_ are advertised with queue sizes of 1. This occasionally causes goals to be dropped. Could these queue sizes be configurable or at least increased?

I was having an issue with compiling when using the message-filter sync policies with custom messages that all contain std-msgs/Header fields. Poking around further, it became clear that the .h file generated for my custom messages do not have HasHeader templates. Cutting and pasting the HasHeader() template from Sensor-msgs/Image.h and changing the names, my code compiles. Look like this is a bug in gencpp for hydro???

In #20, the copyright statement was removed from generated header files. However, this creates an ambiguity. We don't know whether the generated source code has the copyright of the msg file, or the copyright of gencpp (because gencpp creates it).

It would be helpful if the gencpp license statement could be extended to explicitly state what copyright the generated messages are under. Preferably, that should be the copyright of the input file, but BSD would also be acceptable.

Sorry if this seems overly picky, but you know, any ambiguity is bad in legal questions.

The current serialization of ROS messages as generated by the stream operators is not YAML compliant for arrays:
https://github.com/ros/gencpp/blob/indigo-devel/scripts/msg.h.template#L248

If there is no special reason for this, I think this should be changed. This way the output will be the same as provided by rostopic echo and it can be directly written to a .yaml file.

If a comment description line in a .msg file (starting with #) ends in a a special character such as ( ), extra newlines are added in the generated header file which gives compiler errors when included. Example below:

# ICD-XXXXX - Delta Position
# Primary Measurement: Change in position over a time interval (1D, 2D, or 3D)
# Standard Header
Header header 
#1, 2, or 3 elements based on dimension specified in metadata
float64[] delta_pos
# Delta position covariance matrix (row-major) in [units^2] of size nDim x nDim.
# The matrix is linearized into a single array for storage.
float64[]  delta_pos_covariance

generates the header with the following code (note the extra newlines):

template<class ContainerAllocator>
struct Definition< ::MyClass::DeltaPosition_<ContainerAllocator> >
{
  static const char* value()
  {
    return "# ICD-XXXXX - Delta Position
\n\
# Primary Measurement: Change in position over a time interval (1D, 2D, or 3D)
\n\

\n\
# Standard Header
\n\
Header header

moved over from ros/actionlib#2

@dpinol
When compiling in gcc with -Wall -Wextra a file generated I get tons of warnings because of unused parameters in the files generated at the msg_gen/cpp/include/ folder.

template<class ContainerAllocator> struct Serializer< ::face_detector::FaceDetectorGoal_<ContainerAllocator> >
{
  template<typename Stream, typename T> inline static void allInOne(Stream& stream, T m)
  {
  }

  ROS_DECLARE_ALLINONE_SERIALIZER;
}; // struct FaceDetectorGoal_

} // namespace serialization
} // namespace ros

namespace ros
{
namespace message_operations
{

template<class ContainerAllocator>
struct Printer< ::face_detector::FaceDetectorGoal_<ContainerAllocator> >
{
  template<typename Stream> static void stream(Stream& s, const std::string& indent, const  ::face_detector::FaceDetectorGoal_<ContainerAllocator> & v)
  {
  }
};

Hello,
I hope gencpp generates the headers based on service files and the issue is in the right repo.

I use ros indigo ubuntu 14.04:

When I generate a service file and define it like:

int8 <tab> test1
int8 <tab> test2
---
int8 <tab> test3

This does result in a compilation error.
If I define it like:

int8 .. test1
int8 .. test2
---
int8 .. test3

With "." representing "space", the compilation works without an error regarding the service file definition.

Is this intended behaviour?

Best,
Chris

possible to separate into various headers, or maybe via

#ifndef ROSCPP_DISABLE_MESSAGE_SERIALIZATION

The Python generation code contains logic to append with underscore any fields that match a Python keyword:

https://github.com/ros/genpy/blob/45ecd5415fc4711a3afbdf3c2923b59fa742b436/src/genpy/generator.py#L224-L225

However, there's no such thing in the gencpp code, so we got tripped up when we had a message with established Python usage that had class as a field name, and then got used in C++ and wouldn't compile.

For now we've simply renamed our field to class_, but it would be great to see this transformation happen in gencpp itself, as it does in genpy.

Code like this:

int foo = <condition> ?
      diagnostic_msgs::DiagnosticStatus::OK :
      diagnostic_msgs::DiagnosticStatus::ERROR;

Produces this warning:

/home/mpurvis/test_ws/src/test/src/main.cpp: In function ‘int main()’:
/home/mpurvis/test_ws/src/test/src/main.cpp:5:94: warning: enumeral mismatch in conditional expression: ‘diagnostic_msgs::DiagnosticStatus_<std::allocator<void> >::<anonymous enum>’ vs ‘diagnostic_msgs::DiagnosticStatus_<std::allocator<void> >::<anonymous enum>’ [-Wenum-compare]
   int a = false ? diagnostic_msgs::DiagnosticStatus::OK : diagnostic_msgs::DiagnosticStatus::ERROR;

Which seems to happen because OK and ERROR come from different anonymous enums. There's a lot of chatter about this warning on the googles:

https://www.google.ca/search?q=Wenum-compare

But it does seem that moving all message constants into a shared enum would provide a simple fix.

For full introspection, Python is typically the better answer, but we have some cases where we'd like to be able to reference constant names for example in rosparam yaml, or transform variables into the appropriate constants for the purposes of emitting more helpful logs / diagnostics— from the context of a compiled roscpp binary.

A couple of possible ways this might be implemented:

• For integer constants only (since they're already dealt with separately anyway), a function is generated which returns a std::map of constant names to int64_t values, and any constants which can't be upcast to int64_t (eg, uint64_t) are out of luck.
• Some fancy logic examines the integer constants within a given message and determines what single type can safely return all of them (still won't cover a message containing uint64 and int64 constants).
• A function is generated which returns a std::map of constant names to boost::any values (we already depend on boost::shared_ptr and boost::array here, though depending on boost::any would be new).
• A function is generated which returns a vector of just the constant names, and a separate templated getConstantValue function (or suite of functions) is generated which return the value for a given constant name— making it the responsibility of the caller to specify the type they expect (under the hood this would likely be a cascaded-if implementation— not the most efficient, but the list of constants is typically short anyway, and in most uses this will run only at initialization, not runtime).

Regardless of approach, none of this should have a binary-size cost since the unused function will just be optimized away. There will be some impact to compilation time (particularly if the boost::any approach is chosen), but I wouldn't expect it to be significant— if there's concern about this, I can do some measuring in order to put a number on it.

Would a PR for this change be welcome? Preferences on approach to take?

If the msg proto ends without a newline, genpy (IMO correctly) generates the message definition also without this ending newline. On the other hand, gencpp always adds a newline to the last line of definition. This results in different message definitions between gencpp- and genpy- generated files.

See yourself e.g. in geometry_msgs. Vector3 has no ending newline in the proto, and this is what genpy and gencpp generate:

gencpp: "float64 z\n"
genpy:  float64 z"""

I think the difference is caused by this line of code:

The question is - can this be fixed in the already released ROS 1 versions? Or would that be an API-break? Regarding the definitions stored in e.g. rosbags, they already differ depending on whether the publisher was a rospy or roscpp one. So I guess removing or adding the ending newline doesn't actually break anything.

I was surprised when I needed this and it wasn't there. It's brittle to test fields manually in my user code and relatively easy to support it here.

I get this warning on an ARM HF system for all unsigned constants in a msg description:

msg:

uint32 ALL = 4294967295

The generated code for this constant is:

enum { ALL = 4294967295 };

and should be

enum { ALL = 4294967295u };

to get rid of this warning.

Hi,

I originally posted this here: http://answers.ros.org/question/49422/undefined-reference-for-string-constant-in-service/ , then submitted a ticket here: https://code.ros.org/trac/ros-pkg/ticket/5587, so I hope this is in the right place here now ;)

when I define a simple service in Fuerte, e.g.

string my_string
string CONST_STRING=some_value

---

I get an undefined reference to ...::CONST_STRING during linking. Looking at the generated header file, I noticed that CONST_STRING gets declared, but never defined. I tested the same with messages: here it works fine and I can see the definition of CONST_STRING.

The same applies for floatXX-- I guess that problem exists for every constant that can not be encoded into an enum.

Best, Markus

ROS messages have a shared pointer to a _connection_header in the message. This field is unused, and takes a large amount of space (8 bytes on 64bit systems). We should remove this field to make using ROS messages easier.

From the "msg.h.template" file:

// REMOVE THIS FIELD
  boost::shared_ptr<std::map<std::string, std::string> > __connection_header;

Consider the following message spec:

time[] foo

The C++ code generated for this message generates a warning which concerns me, as it indicates invalid code (the actual warning is much longer, cf. instructions below to reproduce):

/usr/lib64/ros/include/ros/serialization.h:451:13: warning: ‘void* memcpy(void*, const void*, size_t)’
writing to an object of non-trivially copyable type ‘__gnu_cxx::__alloc_traits<std::allocator<ros::Time>,
ros::Time>::value_type’ {aka ‘class ros::Time’}; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
       memcpy(&v.front(), stream.advance(data_len), data_len);

It seems that some type trait is missing for such time arrays, such that the proper VectorSerializer is chosen.

You can find an example repository at https://github.com/timn/ros-timebug_msgs. I have tried this with ROS Kinetic. Once it is built in a workspace it prints the warning.

Follows #32 .

What about adding MY_PKG_MESSAGE_MYVECTOR3_PLUGIN_FREE_FUNCTIONS that would be at (or near) the very end of the header file? That'd allow adding more traits and such things.

@dirk-thomas commented

Depending on what you mean with free functions you might be able to just put them into the <pkgname>/plugin/<msgname>.h file.

But this file is included before the message definition file, so you cannot use the defined class or typedefs in the plugin file...

• 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

The dreaded serialization bugs attack again. Ref http://answers.ros.org/question/71107/pandaboard-alignment-trap-when-using-tf/

My platform is a linaro ubuntu precise 12.10 on an odroid xu. The other person with the issue is on the Pandaboard. Note that I don't get this error on my Pandaboard with 12.04 and Fuerte.

Backtrace:

Program received signal SIGBUS, Bus error.
[Switching to Thread 0xb1aff420 (LWP 14419)]
0xb6f65294 in void ros::serialization::VectorSerializer >, std::allocator > >, void>::readros::serialization::IStream(ros::serialization::IStream&, std::vector >, std::allocator > > >&) () from /opt/ros/groovy/lib/libtf.so
(gdb) bt
#0 0xb6f65294 in void ros::serialization::VectorSerializer >, std::allocator > >, void>::readros::serialization::IStream(ros::serialization::IStream&, std::vector >, std::allocator > > >&) () from /opt/ros/groovy/lib/libtf.so
#1 0xb6f65592 in ros::SubscriptionCallbackHelperTboost::shared_ptr<tf::tfMessage_<std::allocator<void > const> const&, void>::deserialize(ros::SubscriptionCallbackHelperDeserializeParams const&) ()
from /opt/ros/groovy/lib/libtf.so
#2 0xb6f0035e in ros::MessageDeserializer::deserialize() () from /opt/ros/groovy/lib/libroscpp.so
#3 0xb6efa376 in ros::SubscriptionQueue::call() () from /opt/ros/groovy/lib/libroscpp.so
#4 0xb6ec4070 in ros::CallbackQueue::callOneCB(ros::CallbackQueue::TLS*) () from /opt/ros/groovy/lib/libroscpp.so
#5 0xb6ec500e in ros::CallbackQueue::callAvailable(ros::WallDuration) () from /opt/ros/groovy/lib/libroscpp.so
#6 0xb6f618f8 in tf::TransformListener::dedicatedListenerThread() () from /opt/ros/groovy/lib/libtf.so
#7 0xb6f61654 in boost::detail::thread_data, boost::_bi::list1boost::_bi::value<tf::TransformListener* > > >::run() () from /opt/ros/groovy/lib/libtf.so
#8 0xb6165602 in thread_proxy () from /usr/lib/libboost_thread.so.1.46.1
#9 0xb6c3ded2 in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#10 0xb62aaf18 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#11 0xb62aaf18 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Originally filed by @icoderaven ros/geometry#39