gazebosim / gz-msgs

Messages for Gazebo robot simulation.

Gazebo Messages: Protobuf messages and functions for robot applications

Maintainer: caguero AT openrobotics DOT org

Build	Status
Test coverage
Ubuntu Jammy
Homebrew
Windows

Gazebo Messages is a component in the Gazebo framework, a set of libraries designed to rapidly develop robot applications.

Installation

See the installation tutorial.

Known issue of command line tools

In the event that the installation is a mix of Debian and from source, command line tools from gz-tools may not work correctly.

A workaround for a single package is to define the environment variable GZ_CONFIG_PATH to point to the location of the Gazebo library installation, where the YAML file for the package is found, such as

export GZ_CONFIG_PATH=/usr/local/share/gz

However, that environment variable only takes a single path, which means if the installations from source are in different locations, only one can be specified.

Another workaround for working with multiple Gazebo libraries on the command line is using symbolic links to each library's YAML file.

mkdir ~/.gz/tools/configs -p
cd ~/.gz/tools/configs/
ln -s /usr/local/share/gz/fuel8.yaml .
ln -s /usr/local/share/gz/transport13.yaml .
ln -s /usr/local/share/gz/transportlog13.yaml .
...
export GZ_CONFIG_PATH=$HOME/.gz/tools/configs

This issue is tracked here.

gz-msgs's Issues

[Citadel] Update JointCmd and PID messages to support optional fields

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

In gazebo::msgs and ign-msgs2 and earlier, we used proto2 syntax, in which it could be determined which fields were unset. Since ign-msgs3, we are using proto3 syntax, in which unset fields of primitive leaf types (string, int, float, etc) are indistinguishable from fields with a default value. This is problematic for the JointController in osrf/gazebo, in which position PID, velocity PID, and force control can be applied additively in any combination. It is common to use a PID control along with a feed-forward force parameter to counteract constant disturbances (like gravity compensation).

Currently this is problematic for the JointCmd and PID messages because JointCMD::force is a double, and the target and gain values in PID are double. So it will work if you are only sending a force, but if you simply want to update the target of a PID controller, that will reset the force and the PID gains unless you repeat those values.

cc @chapulina @iche033 @azeey

Let's think about doing this before the ign-msgs5 cutoff.

proto syntax is not specified

Original report (archived issue) by Anonymous.

---

I just noticed we don't specify syntax = "proto2"; on the protos. Is there any reason why? Certain versions of protoc complain very loudly about this.

Proposal: remove edit_name from factory message

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Summary

The entity_factory message has an edit_name field which is supposed to edit an existing model, instead of spawning a new one. On Gazebo <= 9 this has limited support. I suggest we remove it in favour of using other message types for more granular entity updates.

Motivation

• Simplify the factory message: it should be used only to spawn new entities, not to edit them
• Simplify implementation: to fully support editing an existing entity from any arbitrary SDF means that we either truly support any changes, such as new kinematics, or we print lots of errors to catch all the unsupported cases. Instead, we can have dedicated messages for editing specific things in simulation that are well defined and tested, like changing pose, scale, name...

Describe alternatives you've considered

We can keep the field and deal with all the corner cases that will come up.

Alternatively, we could document the scope of what the edit_name should be able to accomplish. For example, on Gazebo 9 it doesn't support adding a link.

Testing failures in armhf for InitPointCloudPacked

I'm seeing problems with testing on armhf platform related to fileds in PointCloudPacket. I'm not sure if the software is fine and we need to fix the test or the opposite. This is happening when building ign-msgs5 branch:

[ RUN      ] UtilityTest.InitPointCloudPacked
/var/lib/jenkins/workspace/ign-msgs5-debbuilder/build/ignition-msgs-5.3.0/src/Utility_TEST.cc:689: Failure
Expected equality of these values:
  24u
    Which is: 24
  pc.point_step()
    Which is: 16
/var/lib/jenkins/workspace/ign-msgs5-debbuilder/build/ignition-msgs-5.3.0/src/Utility_TEST.cc:707: Failure
Expected equality of these values:
  16u
    Which is: 16
  pc.field(3).offset()
    Which is: 12
[  FAILED  ] UtilityTest.InitPointCloudPacked (6 ms)

Documentation for generated C++

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

See this gazebo issue

And this question

Expose message generation framework

Original report (archived issue) by Anonymous.

---

Summary

I'm trying to add custom messages to my ignition project. Since ign-msgs doesn't seem to expose this functionality, I had to copy the cmake macro ign_msgs_protoc from ign-msgs/src/CMakeLists.txt into my own project, along with the generator source files: ign-msgs/src/Generator.cc, ign-msgs/src/Generator.hh, ign-msgs/src/generator_main.cc. Although this works, it's not a clean solution. Are there any plans to export the message generation framework so it can be used by other projects?

The ignition-msgs1_1.0.0 tag does not match the released version 1.0.0

Original report (archived issue) by Silvio Traversaro (Bitbucket: traversaro).

---

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:

  • Checked the Q&A board for common solutions: http://answers.gazebosim.org
  • Checked that your issue isn't already filed.
  • Checked that there is not already an Ignition package that provides the described functionality: https://ignitionrobotics.org/libs

Description

For some reason, the tag ignition-msgs1_1.0.0 does not match the released version tarball available at https://osrf-distributions.s3.amazonaws.com/ign-msgs/releases/ignition-msgs-1.0.0.tar.bz2 . In particular, the tag ignition-msgs1_1.0.0 seems to miss all the commits related to the complete adoption of ignition-cmake .

Steps to Reproduce

1. Compare https://github.com/ignitionrobotics/ign-msgs/blob/master/ with https://osrf-distributions.s3.amazonaws.com/ign-msgs/releases/ignition-msgs-1.0.0.tar.bz2 and

Expected behavior:

I expect the tag and the released version to be consistent.

Actual behavior:

The released tarball and the tag do not match.

Reproduces how often:

Always.

Versions

1.0.0

CMAKE_BUILD_TYPE=None not supported

Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).

---

A home-brew build with default arguments uses CMAKE_BUILD_TYPE=None, which generates the following error:

-- BUILD ERRORS: These must be resolved before compiling.
-- 	CMAKE_BUILD_TYPE None unknown. Valid options are: Debug Release RelWithDebInfo Profile Check
-- END BUILD ERRORS

Here's the formula. We have a similar issue in many of our other packages that use this cmake code. As a workaround I can specify the release type, but it seems bad to fail like this.

Unversioned files lib/ruby/ignition/msgs/*.rb conflict between flavors for different versions

Original report (archived issue) by yurivict (Bitbucket: yurivict).

---

They can't be installed together.

Document policy for message modification

We can't modify messages within a major release because that would break ABI for the generated C++ classes.

How about in between releases? How do we tick-tock the change / removal of message fields?

We should decide on a policy and document it.

PointCloudPackedUtilsTest.MultipleFields fails on armhf

Environment

• OS Version: Ubuntu 18.04, 20.04
• Source or binary build? armhf deb builder job of 5.9.0 and 7.3.0

Description

• Expected behavior: UNIT_PointCloudPackedUtils_TEST passes
• Actual behavior: UNIT_PointCloudPackedUtils_TEST fails with an exception during PointCloudPackedUtilsTest.MultipleFields
  • Ubuntu 20.04 armhf debbuild 5.9.0: https://build.osrfoundation.org/job/ign-msgs5-debbuilder/160/
  • Ubuntu 18.04 armhf debbuild 7.3.0: https://build.osrfoundation.org/job/ign-msgs7-debbuilder/318/

Steps to reproduce

1. Compile ign-msgs on armhf
2. Run UNIT_PointCloudPackedUtils_TEST test

Output

11/12 Test  #3: UNIT_PointCloudPackedUtils_TEST .........Bus error***Exception:   0.23 sec
Running main() from gtest_main.cc
[==========] Running 5 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 5 tests from PointCloudPackedUtilsTest
[ RUN      ] PointCloudPackedUtilsTest.BadFields
Field [x] does not exist.
Field [xyz] does not exist.
Field [r] does not exist.
[       OK ] PointCloudPackedUtilsTest.BadFields (0 ms)
[ RUN      ] PointCloudPackedUtilsTest.Operators
[       OK ] PointCloudPackedUtilsTest.Operators (0 ms)
[ RUN      ] PointCloudPackedUtilsTest.MultipleFields

12/12 Test #11: UNIT_ign_TEST ...........................   Passed    0.73 sec

Make ign-msgs2 prerelease

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Now that we have ign-cmake1 support, we should make a prerelease.

Unmet dependency in Ubuntu Trusty

Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).

---

After trying to install libignition-msgs-dev in Ubuntu Trusty:

#!c++

The following packages have unmet dependencies:
 libignition-msgs-dev : Depends: libignition-msgs0 (= 0.1.0-1~trusty) but it is not installable

However, I can see a package named libignition0-msgs. It looks like the 0 has been moved but we haven't updated the dependency.

Need an ign_math2 compatible branch

Original report (archived issue) by Tully Foote (Bitbucket: Tully Foote, GitHub: tfoote).

---

I'm building sasc from source and just recently it looks like ign_msgs switched to using ign_math3 from ign_math2. However sdformat requires ign_math2 which broke the sasc build. Can an ign_msgs2 branch be created and maintained here?

Change of dependency: https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-msgs/commits/88092155f59bce1bdcec31c9b8c68007a4fba1df?at=use_ign_math3

I've rolled back to the commit for 0.6.1 for now. (ffd16db)

Scene CreateAxisVisual message equivalent?

I was looking for an equivalent message to use for creating visual axis in my application, but it appears one does not exist. I do see an axis message but I believe it is related to joint axis not a visual axis. I would like to create a message for this visual type and contribute back but wanted to reach out to see what name the maintainers would like to used to represent a scene visual axis?

What is the purpose of ignition::msgs::Double_V?

What is the best use case for ignition::msgs::Double_V?

I can see the documentation at https://ignitionrobotics.org/api/msgs/5.3/classignition_1_1msgs_1_1Double__V.html#af5fc2c48339eb12a5c2c09eeecf19ca5

but it doesn't tell me where to use this kind of message?

Simple Windows compilation issues

Original report (archived issue) by Renato Cherullo (Bitbucket: rcherullo).

---

Hi all,

While compiling for Windows in VS2017, I get the following errors:

#!

4>C:\gz-ws\osrf\ignition-msgs1\tools\ign_TEST.cc(29): error C3861: 'popen': identifier not found [C:\gz-ws\build\osrf\ignition-msgs1\tools\UNIT_ign_TEST.vcxproj]

4>C:\gz-ws\osrf\ignition-msgs1\tools\ign_TEST.cc(43): error C3861: 'pclose': identifier not found [C:\gz-ws\build\osrf\ignition-msgs1\tools\UNIT_ign_TEST.vcxproj]

4>C:\gz-ws\osrf\ignition-msgs1\tools\ign_TEST.cc(93): error C3861: 'setenv': identifier not found [C:\gz-ws\build\osrf\ignition-msgs1\tools\UNIT_ign_TEST.vcxproj]

The fix is quite simple, maybe I could create a pull request for it: popen and pclose can be replaced with _popen and _pclose, while setenv can be replaced with _putenv_s. This works and the tests pass.

The question is how to implement this platform check? #ifdefs? Extract those methods to another file and do the checks there? Looking forward for your guidance.

[]s Renato C.

Trusty build broken because of protobuf version

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Step 20 : RUN gem install protobuf
 ---> Running in 06db901b5f09
ERROR:  Error installing protobuf:
	activesupport requires Ruby version >= 2.2.2.

I tried a few different things in release-tools branch ign_msgs_trusty, it goes a bit further but it still doesn't build all the way through.

Optional fields in proto 3

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

On Protobuf 3 all fields are optional, but only nested messages have the has_msg API (i.e. leaf fields don't have a has_field). Protobuf will also automatically set default values to fields which are unset, such as 0 to int and false to booleans.

This means that it is impossible to know if a boolean was set to false or if it is unset.

For example, the WorldStatistics message has the following fields:

bool paused
int32 model_count

When receiving a message with paused false and zero models, we don't know if that's indeed true.

This could be just something to be aware from the publishing side (i.e. make sure to always set leaf fields), or maybe we want to restructure the messages to avoid this.

One suggestion would be to change leaf fields for nested messages, for example:

Boolean paused
Int32 model_count

Jenkins CI jobs not started for pull requests

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

This pull request didn't have any jenkins CI jobs started automatically:

• https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-msgs/pull-requests/36/fix-protobuf-3-warnings-issue-17/diff

The last CI jobs appear to have been from January:

• https://build.osrfoundation.org/view/main/view/ignition/job/ignition_msgs-ci-pr_any/

Any ideas @_jrivero_ ?

Deleted issue

This issue was deleted on BitBucket and was thus not migrated to GitHub

Factory and multiple messages in a proto file

While debugging gazebosim/gz-gui#69, I noticed that the Factory::New function fails for ignition.msgs.SerializedStepMap. This test currently fails:

diff --git a/src/Factory_TEST.cc b/src/Factory_TEST.cc
index c5d6516..28d7a52 100644
--- a/src/Factory_TEST.cc
+++ b/src/Factory_TEST.cc
@@ -78,3 +78,12 @@ TEST(FactoryTest, NewDynamicFactory)
   msg = msgs::Factory::New("example.msgs.StringMsg");
   EXPECT_TRUE(msg.get() != nullptr);
 }
+
+/////////////////////////////////////////////////
+TEST(FactoryTest, NewSerializedStepMap)
+{
+  auto msg = msgs::Factory::New<msgs::SerializedStepMap>(
+      "ignition.msgs.SerializedStepMap");
+
+  ASSERT_NE(nullptr, msg.get());
+}

I noticed that the serialized_map.proto file doesn't have the option java_outer_classname line like other messages do. But when I added it, I noticed that that proto file has multiple messages defined, so we can add only one classname. I checked that adding

option java_outer_classname = "SerializedStepMapProtos";

fixes the test, but only for the 1st message defined in the proto file - whichever one it is.

If we ignore the factory issue, the message works otherwise. We've been publishing and using a few messages from serialized_map.proto on ign-gazebo without issues.

I'm wondering if the only solution to this is splitting the messages into multiple files, or if there's another more appropriate solution to this. I think moving the messages to other files wouldn't break API / ABI as long as the existing message includes all others.

Add light map field to material.proto

needed by ign-gazebo so we can convert the lightmap uri in SDF DOM to protobuf msgs and vice versa.

This would be an ABI breaking change.

Related pull request: gazebosim/gz-sim#471

Documentation out of date?

Original report (archived issue) by Thorsten von Eicken (Bitbucket: tvoneicken).

---

Looking at the documentation at https://osrf-distributions.s3.amazonaws.com/ign-msgs/api/0.1.0/classes.html I see no reference to the Marker messages. Are the docs out of date?
Overall the docs for the messages seem pretty useless, one has to go to the source. Maybe it's because I'm new to all this (but isn't that what docs are for?)...

InitPointCloudPacked test failed on i386

Original report (archived issue) by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero).

---

Prerequisites

‌ [x] Put an X between the brackets on this line if you have done all of the following:

‌ * Checked the Q&A board for common solutions: http://answers.gazebosim.org

‌ * Checked that your issue isn't already filed.

‌ * Checked that there is not already an Ignition package that provides the described functionality: https://ignitionrobotics.org/libs

Description

The InitPointCloudPacked is failing on i386. I've detected it in the i386 package build: https://build.osrfoundation.org/view/main/view/ignition/job/ign-msgs4-debbuilder/167/console

[ RUN      ] UtilityTest.InitPointCloudPacked
/var/lib/jenkins/workspace/ign-msgs4-debbuilder/build/ignition-msgs-4.5.0/src/Utility_TEST.cc:651: Failure
Expected equality of these values:
  24u
    Which is: 24
  pc.point_step()
    Which is: 16
/var/lib/jenkins/workspace/ign-msgs4-debbuilder/build/ignition-msgs-4.5.0/src/Utility_TEST.cc:669: Failure
Expected equality of these values:
  16u
    Which is: 16
  pc.field(3).offset()
    Which is: 12
[  FAILED  ] UtilityTest.InitPointCloudPacked (0 ms)

Steps to Reproduce

1. Build the software on i386 and run the test suite

Expected behavior:

Pass the test

Actual behavior:

Failing test

Reproduces how often:

always

Versions

ubuntu bionic i386 for 4.5.0 msgs version

CmdLine.Msg* test failures on homebrew

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

The CmdLine.MsgList and CmdLine.MsgInfo tests used to pass but are failing since were added in pull request #56 but fail on homebrew.

Error class xxx has no member named ‘has_xxx’

Original report (archived issue) by Guanghua Zha (Bitbucket: sky99198).

---

I am trying to build gazebo 7.1 from source and I am getting a type of error says:

error: ‘const class ignition::msgs::Marker’ has no member named ‘has_layer’; did you mean ‘has_header’?
if (_msg.has_layer())

I am using ign-msgs 5.0 which I build from source.

I know this function suppose to check whether a member is existed in that class but that function is not implemented or removed in newer version of ign-msgs.

I plan to change all such function to:

if (_msg.layer()!=nullptr)

‌

Will that work?

Thanks!

Debugging symbols in packages?

Hi, I've just noticed the packages distributed via osrfoundation repo do not have debugging symbols. And there are no -dbg packages. That's pretty unfortunate as you can't peek inside the messages when debugging. Is there any chance these packages could be built and distributed? Or am I overlooking something?

Test failures on windows

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

The windows build started failing after merging pull request #31, since the old ign-math3.zip archive did not have the Color.hh header files. So I made a new ign-math3.zip from the 3.2.0 tag, which fixed the build failure, but now the tests are failing:

• https://build.osrfoundation.org/job/ignition_msgs-ci-default-windows7-amd64/79/testReport/

Add support for cross-compilation

Original report (archived issue) by Silvio Traversaro (Bitbucket: traversaro).

---

Summary

It would be great to be able to compile the C++ library ignition-msgs, to compile it for target platform different from the one in which the project is being built (see https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html#cross-compiling and https://en.wikipedia.org/wiki/Cross_compiler for some background on cross compilation). As ignition-msgs require code generation with tools that are compiled as part of the project itself, this is not trivial.

Motivation

Cross compilation is quite common, for example it is used when targeting embedded targets or WebAssembly.

Describe alternatives you&#39;ve considered

A typical approach for cross-compilation of projects that require code generation as this one, is to have a parallel installation of the code generator for the host machine, and use that for code generation. An alternative is just to use the host project build system to generate the necessary C++ files, and use them directly in the cross compilation.

Based on this, I think there are two main alternatives to tackle this:

• One is to install the ign_msgs_gen protobuf plugin and install it in the host project, and then add options to manually specify an external protoc compiler and an external ign_msgs_gen protobuf plugin, that will be used in the cross-compiled project to use the host code generators.
• An alternative is to add an option to install or export in some form the generate C++ code (that will be used in the host project), and add an option to avoid generation of the C++ code, and just use it externally (this option will be used in the cross-compiled project).

Additional context

The main motivation for tackling this issue is to be able to support all officially supported vcpkg triplets, see microsoft/vcpkg#8044 .

Bazel support

Original report (archived issue) by kgreenek (Bitbucket: kgreenek).

---

I'm trying to use ignition transport with my bazel project. The issues I'm running into have to do with the custom code that's added to the generated c++ files by Generator.cc. This prevents me from using the standard protobuf tools, which is creating a surprisingly large headache for me.

As far as I can tell, the stuff that's added in the generated c++ code is just for convenience (adding a SharedPtr type, for example). It also registers the message types with Factory by using a macro at static scope, but there are nicer ways to handle that as well.

I propose simply using standard protoc commands (no custom protobuf generator). Besides just others who want to use your code with Bazel, this will also help anyone else using a build system other than your cmake file.

Autogenerated protobuf code as public API

Currently the c++ code autogenerated by protobuf is used in the public API of ign-msgs. While this is convenient in that users of ign-msgs can just link against ign-msgs and immediately start using the message classes in their applications, it comes with some downsides.

1. Adding a field to a message breaks ABI even though the wire protocol of protobuf is designed to be backward compatible. This this requires a major version bump whereas adding a completely new message can be done in a minor release of ign-msgs.
2. Platforms like macOS with more frequent updates suffer from breakages caused by updates to libprotobuf. Even minor version updates need new bottles. osrf/homebrew-simulation#1205
3. Incompatibility with other versions of libprotobuf installed on the system. gazebosim/gazebo-classic#2496

A potential solution for (1) would be to make ign-msgs only contain the .proto files and generate message classes in each downstream library. For (2) and (3), we could consider statically link against libprotobuf as recommended in
https://github.com/protocolbuffers/protobuf/tree/master/src#binary-compatibility-warning

ign_TEST disabled on windows

Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).

---

Description

We haven't verified that the command line tools work on Windows, and on pull request #103 they're being skipped.

Steps to Reproduce

1. Install on Windows
2. Try some command, such as ign topic -l

Expected behavior:

No errors printed

Actual behavior:

Unknown

Reproduces how often:

Unknown

Versions

All

/bigobj required on Windows MSVC with Protobuf 3.12

I did not checked myself, but it seems that on Windows with Protobuf 3.12 it is necessary to add the /bigobj flag, see microsoft/vcpkg#11397 (comment) .

Add doxygen blocks for autogenerated code

Pull request #76 is adding autogenerated code to our documentation alongside the rest of the API. Now that we have that, we should also inject some documentation into that generated code.

Is it ok to install both ign-msgs5 and ign-msgs7?

Hi,

I am trying to build Gazebo 11 on openSUSE Linux.

Ignition-transport8 need Ignition-msgs version 5.
Ignition-fuel-tools6 need Ignition-msgs version 7.

Would it be ok to use 2 version of ign-msgs like this or do I have to down-grade Ignition-fuel-tools to make it use Ignition-msgs version 5?

Thanks.

Compilation Error related to shared library

Original report (archived issue) by rishabh lal (Bitbucket: Riss0).

---

[X] Put an X between the brackets on this line if you have done all of the following:
    * Checked the Q&A board for common solutions: http://answers.gazebosim.org
    * Checked that your issue isn't already filed.
    * Checked that there is not already an Ignition package that provides the described functionality: https://ignitionrobotics.org/libs
# Description 

[Compilation Error, when linking of shared library libignition-msgs5.so starts]
# Steps to Reproduce
Just followed the installation instructions
**Expected behavior:**  

[100% compilation, without any error]
**Actual behavior:**

[
[ 97%] Linking CXX shared library ../lib/libignition-msgs5.so
/usr/bin/ld: /usr/local/lib/libprotobufd.a(arena.cc.o): relocation R_X86_64_32 against `_ZN6google8protobuf8internal9ArenaImpl23lifecycle_id_generator_E' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libprotobufd.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
src/CMakeFiles/ignition-msgs5.dir/build.make:4109: recipe for target 'lib/libignition-msgs5.so.5.0.0' failed
make[2]: *** [lib/libignition-msgs5.so.5.0.0] Error 1
CMakeFiles/Makefile2:1134: recipe for target 'src/CMakeFiles/ignition-msgs5.dir/all' failed
make[1]: *** [src/CMakeFiles/ignition-msgs5.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2
]
**Reproduces how often:** 

[Occurs at last, always]
# Versions

[My protobuf is 3.7.1 on ubuntu 16.04 with ignition-msgs5]

Actuators message fields assume rotation, don't consider translational

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Summary

I noticed that the Actuators message added in pull request #123 has field names based on rotation, which would be awkward to use with a linear actuator on a prismatic joint.

Motivation

In gazebo7, the Joint API was also very rotation-centric, but we made an explicit choice to rename functions like GetAngle(int) to Position(int) to be more general. I realize that this message was inspired by one that explicitly uses rotation-centric field names, but I expect we want a more general field names?

Describe alternatives you've considered

Leave it as-is.

Incorrect namespace for ConstXXXSharedPtr

Original report (archived issue) by Michael Grey (Bitbucket: mxgrey, GitHub: mxgrey).

---

The protoc plugin for ign-msgs is currently defining Const<Msg>SharedPtr in the wrong namespace: https://github.com/ignitionrobotics/ign-msgs/blob/de0ebdc8406d46de121eb758f9625785ce454603/src/Generator.cc#L164

Taking the Altimeter message as an example, this means that we'll generate ::ignition::msgs::AltimeterUniquePtr, ::ignition::msgs::AltimeterSharedPtr, and ::ConstAltimeterSharedPtr. Notice that the last one is in the global namespace.

I'm making a fix to this which will go into pull request #40, but I'm not sure if we should deprecate the globally namespace typedef or just remove it entirely. What do we think the risk would be that someone is already using that typedef in the global namespace? It seems that it was added nearly 3 years ago, so the risk seems non-trivial.

For now, I'll just deprecate it (conveniently, our export macros are available to the auto-generated messages). If anyone thinks we should move forward with deleting it entirely, feel free to voice your opinion.

Remove header from image.proto. Remove time from image_stamped.proto

Original report (archived issue) by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

image_stamped.proto has three fields: header, time and image.
image.proto also has a header field.
header.proto has a time field. This means image_stamped.proto has three time fields, one in header.time, one in image.header.time, and time. Which one is the authoritative time?

This can be fixed by removing header from image.proto, and removing time from image_stamped.proto. Then image_stamped.proto will only have one time in it's header, and image.proto won't have any time at all. It also reduces the size of any message that wants to include an image image.proto, but doesn't need an extra header attached to it.

Add tests

Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).

---

We have not a single test defined in the software and changes are hard to be sure about not creating regressions.

Installation Error:include could not find load file

As following the instructions to run gazebo i came across this :
C:\Users\abdhi\ign-msgs>cd /d C:\Users\abdhi\ign-msgs\

C:\Users\abdhi\ign-msgs>md build

C:\Users\abdhi\ign-msgs>cd build

C:\Users\abdhi\ign-msgs\build>cmake .. -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=""install\Release"" -DCMAKE_BUILD_TYPE="Release" -DBUILD_TESTING:BOOL=False
-- The C compiler identification is MSVC 19.26.28806.0
-- The CXX compiler identification is MSVC 19.26.28806.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.26.28801/bin/Hostx86/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.26.28801/bin/Hostx86/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at C:/Users/abdhi/ign-cmake/build/ignition-cmake0-config.cmake:47 (include):
include could not find load file:

IgnCMake

Call Stack (most recent call first):
CMakeLists.txt:12 (find_package)

CMake Error at CMakeLists.txt:17 (ign_configure_project):
Unknown CMake command "ign_configure_project".

-- Configuring incomplete, errors occurred!
See also "C:/Users/abdhi/ign-msgs/build/CMakeFiles/CMakeOutput.log".

Proto file licensing

Original report (archived issue) by Rich Mattes (Bitbucket: richmattes).

---

During the course of a Fedora review, it came up that the .proto files don't have any licensing information embedded in them. I don't doubt that they're Apache 2 like the rest of the project, but do you think it's worth it to add the Apache preamble to them?

Command line tools broken

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Help seems to work (ign msg -help), but other commands look broken:

$ ign msg -l
/usr/lib/ruby/1.9.1/dl/import.rb:227:in `import_function': cannot find the function: ignitionMSgsVersion() (DL::DLError)
	from /usr/lib/ruby/1.9.1/dl/import.rb:133:in `extern'
	from /usr/local/lib/ruby/ignition/cmdmsgs0.rb:114:in `execute'
	from /usr/local/bin/ign:256:in `<main>'

$ ign msg -i ign_msgs.StringMsg
/usr/lib/ruby/1.9.1/dl/import.rb:227:in `import_function': cannot find the function: ignitionMSgsVersion() (DL::DLError)
	from /usr/lib/ruby/1.9.1/dl/import.rb:133:in `extern'
	from /usr/local/lib/ruby/ignition/cmdmsgs0.rb:114:in `execute'
	from /usr/local/bin/ign:256:in `<main>'

no release for Ubuntu 18.04

Original report (archived issue) by pierre kancir (Bitbucket: pkancir).

---

Hello,

The release for Ubuntu 18.04 comes from Ubuntu and not OSRF. The main issue is that the package is build with protobuf 2.4 when Ubunut 18.04 uses protobuf > 3.0. That prevent to build plugin for Gazebo ...
Can you make a release that fix this bug ?

Thanks

Linked to https://bitbucket.org/osrf/gazebo/issues/2496/protobuf-error-on-ubuntu-1804

Incomplete page on ignitionrobotics.org

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

• The listed version is 0.1
• The API documentation link is also only for 0.1
• The tutorials link goes back to the root website

http://ignitionrobotics.org/libraries/messages

Incorrect issue link in documentation

Original report (archived issue) by Thorsten von Eicken (Bitbucket: tvoneicken).

---

The documentation page https://osrf-distributions.s3.amazonaws.com/ign-msgs/api/0.1.0/index.html has a statement "Should you find problems with this documentation - typos, unclear phrases, or insufficient detail - please create a new bitbucket issue." but the link in that statement points to a 404.

Install Ruby messages on versioned directory

Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Description

As of pull request #47 (released first into ign-msgs3), ruby messages are being installed at an unversioned directory, i.e. lib/ruby/ignition/cmdmsgs3.rb in my local install. It looks like the debs aren't installing them though. We noticed the problem while trying to create homebrew bottles for ign-msgs4, and the files are conflicting.

Steps to Reproduce

1. Install ign-msgs3
2. Install default

Expected behavior:

They should be installed side-by-side in versioned directories. I don't know how these files are being used, so I'm not sure what the appropriate directory structure would be. cc @nkoenig

Actual behavior:

The *_pb.rb messages are overwritten.

Versions

ign-msgs3 and default

Additional Information

For now, we're making the bottles for v3 and v4 conflict, so they're not side-by-side installable.

Missing Cone Geometry Message

The scene in ignition-rendering supports Cone but currently there is no message for ConeGeom.

Move Image::PixelFormat here to remove implied dependency on gazebo::common

Original report (archived issue) by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz).

---

image.proto references an enum Image::PixelFormat. As far as I can tell it is defined in gazebo::common::Image::PixelFormat and nowhere else. This definition should be moved here so code publishing or receiving images does not depend on gazebo.