4am-robotics / cob_driver Goto Github PK

see discussion in https://github.com/ipa320/msh/issues/595#issuecomment-277238899.

this was caused by the charging flag from the bms switching to false as soon as the battery is full because there is no more current going into the battery.

Proper solution is to use a combination of the charging and battery_full flags and generate a docked status out of it. the PowerState message should be enhanced to have this additional flag.

@fmessmer FYI

In ScannerSickS300.cpp getScan() function always returns iTimeNow=0;
and does not assign value to iTimestamp. This is used by cob_sick_s300.cpp in publishLaserScan() to calculate the message timestamp.

            // Sync handling: find out exact scan time by using the syncTime-syncStamp pair:
            // Timestamp: "This counter is internally incremented at each scan, i.e. every 40 ms (S300)"
            if(iSickNow != 0) {
                syncedROSTime = ros::Time::now() - ros::Duration(scan_cycle_time);
                syncedSICKStamp = iSickNow;
                syncedTimeReady = true;

                ROS_DEBUG("Got iSickNow, store sync-stamp: %d", syncedSICKStamp);
            } else syncedTimeReady = false;

Since it's not implemented it only obfuscates the code while always ending up with ros::Time::now().

Will the timestamp calculation be implemented?

@fmessmer FYI

this happens e.g. for
mode = 3
frequency = 20

could be related to the way the messages are published. Probably solving together with #181

In order to be able to use new namespaces with cob3-X the follow_joint_trajectory action name in cob_head_axis should be adjusted!

The relevant lines are:

• https://github.com/ipa-fxm/cob_driver/blob/indigo_dev/cob_head_axis/ros/src/cob_head_axis.cpp#L143
• https://github.com/ipa-fxm/cob_driver/blob/indigo_dev/cob_head_axis/ros/src/cob_head_axis.cpp#L579

Instead of using the node name as part of the action name, I'd prefer to introduce a string variable

action_name_ = "follow_joint_trajectory"

Further adjustments might be required for the joint_state publisher, parameters,...and other stuff in the constructor...

See my comments about "Warning B" in ipa320/cob_simulation#87 (comment)

So far, we are using the same yaml for simulation and real hardware. This leads to the following warning:

[ WARN] [1439833261.548182269]: Serial connection on /dev/ttyLed failed.

In that yaml sim_enabled is set to false...thus, in simulation you cannot actually use sim_enabled

Maybe we should make it a private parameter that can be set via launch file argument in https://github.com/ipa320/cob_robots/blob/indigo_dev/cob_bringup/drivers/light.launch?

@ipa-bnm what do you think?

e.g. messages in cob_sound (currently cob_script_server depends on cob_driver only due to messages in cob_sound)

publish as Float64 and the cast to bool in power_state_aggregator.py

charging= (int(msg.data) & (1<<BIT_NR)) == (1<<BIT_NR)

Hello everyone,

I am working with sick s300 advanced sensors for a UAV project. My system is designed with ROS and thanks to your work I have compatibility with sick and ROS.

The sick is connected via a RS-422 interface set up at 500k baud on continuous data transfer, it works.

However, I do observe a rate of scan transfer (on the topic) of 12 Hz only. [EDIT] with a publish_frequency set at 50
I was wondering if anyone had similar results, it sounds a bit low rate for a scanner that will be use for autonomous driving. Is this limited by the RS-422 or there is another bottleneck that I don't see?

If anyone can share experience on that I'll be grateful!

Best regards,
Etienne H.

PS: sorry if raising an issue for this is not appropriate!

with the previous version there was a CPU load of <10% per scanner

@ipa-jsf
@ipa-rmb

Is this package still needed?
Can you please clean this up?

message generation is not triggered before building sources.

Error log:
In file included from /u/fmw/git/care-o-bot/src/cob_driver/cob_light_sim/src/qnode.cpp:18:0:
/u/fmw/git/care-o-bot/src/cob_driver/cob_light_sim/src/../include/cob_light_sim/qnode.hpp:24:38: fatal error: cob_light/ColorRGBAArray.h: No such file or directory
#include <cob_light/ColorRGBAArray.h>

very sporadic error and not permanently reproducible.
because ros didn't wrote the log, the console-output "Error sending stageprofi" are all i have.

Hello,

I tried to extend the cob_omni_drive_controller in order to add a new feature for the raw3-5. I noticed that there are some header files in the src directory of the library (GeomController.h and WheelControllerBase.h). Is there any reason why they are not in the include directory?

Thanks,
Andreea

After a few minutes in operation, the driver is stopping and throwing the following Warning:
[ WARN] [1416839000.117379774]: Can not write to serial port. Port closed!

this happened e.g. with
mode = 3
frequency = 20

and
mode = 5
frequency = 10

If velocity twist message has some of the values NaN this value is not filtered out but rather the wheels are starting uncontrollably rotate (around steering axis) and platform shuts down (probably because of to high current). This case should be avoided by checking the input values by corresponding components.

frequency in breath mode should be used similar to flash mode. E.g. a frequency of 3 Hz should breath 3 times per second (on-off-on-off-on-off)

This compiler warnings should get fixed:

• cob_phigets
  • implicit conversion from 'double' to 'unsigned int' changes value from 0.5 to 0
• cob_light
  • control reaches end of non-void function (no return value)
  • control reaches end of non-void function (no return value)

Some discussion history from ipa320/cob_robots#367 (comment)

@ipa-fxm:
On a side note:
@ipa-fmw thought that 100Hz might be faster than the actual scanner publish rate....Should the rate be > reduced?
@ipa-bnm What do you think?

@ipa-mig:
@ipa-fxm @ipa-fmw @ipa-bnm Yes, the rate of 100Hz is (considerably) faster than the scanner publish rate (which is 12Hz for the S300, afaik). However, this is on purpose to send out the combined scan asap.
It is not deterministic in which order the single scan topics come in and it is, in the worst case, almost one full scan rate cycle delay. This is due to the scan_unifier waiting until it received information from every scan before it combines one.
This frequency was chosen to be high to check the subscriber callbacks frequently to introduce as little latency between the original scans and the combined one as possible.
However, it could still be beneficial to change this frequency...

Some hints that might help reduce the update rate while guaranteeing the desired behaviour:

• In order to ensure a certain publish rate for the assembled scan, a ros::Timer callback can/should be used
• in order to sync multiple input topic (i.e. the scan topics) depending on their arrival time, message_filters can/should be used (e.g. TimeSynchronizer)

Some questions to decide on best implementations:

• What is more important: a guaranteed publish rate for the assembled scan? or that the assembled scan is complete, i.e. it consists of the latest scan from each of the configured input scans?
• Would it be acceptable to publish a partial assembled scan, i.e. do not include scans from all input scans in case one did not arrive within a given time period?

@ipa-bnm could you also create a new issue for the assembling bug that you told me about? so that it is documented!

Currently, there is was (commented out in #317) a warning about using the fields parameter, as this is the way to go.

"No params for the Sick S300 fieldset were specified --> will using default, but it's deprecated now, please adjust parameters!!!"

However, this is not properly implemented. The driver only supports one field, which defeates the purpose of this parameter. Also, this parameter is nowhere documented.

EDIT answering @ipa-fxm's question below

To be set in the laser yamls (e.g. here)
Old config (without fields param):

"New" config (with fields param and quite some trial-and-error):

fields:
  "1":
    start_angle: -0.75
    stop_angle: 0.0
    scale: 1.0
  "2":
    start_angle: 0.0
    stop_angle: 0.75
    scale: 1.0

What needs to be done:

• check that the max scan fields is 5 in this file.
• check the numbering in the params in this file
• this getScan function seems to only handle the last / one field. However, all configured fields come in one telegram.
• the retrieved fields (which can be arbitrary ranges within [-135°, 135°] without overlaps but with gaps) need to be combined correctly to in the publishLaserScan function which is not done as well.

All in all, my guess is this feature has been implemented without any tests, has never been used, and probably is even unnecessary.

Implementing this correctly would lead to a full driver covering much of the possibilities of the scanner. However, in ROS, this is imo not required. We can easily get the fields we want without having to configure the scanner by using the cob_scan_filter (or, prefereably, the laser_filters).

• better transition between starting/ending of mimic, i.e. start of vlc
• get rid of "Download media content" pop-up
• maybe implement in C++ (performance?)

required for replacing phoenix gui....

Dear all,

We have a robotnik 6 dof robot arm with Schunk Powercube actuators.
People from Schunk told us that their actuators work with a position control loop. However, we have been analyzing the “cob_trajectory_controller” and it sends velocity setpoints to the schunk_powercube_chain node.
What is the reason to send velocity setpoints? Is there a conversion from velocity to position in the schunk driver to feed the actuators?

Thanks

missing install tag

current workaround is to use respawn=true in the launch file. Needs more investiagtion why it crashed

@fmessmer FYI

parameters are hardcoded to /sound_controller/mode

@thiagodefreitas: please add some comment here to indicate for what led_numbers and colors can be used. (e.g. which mode, default value, ...). Should be similar to the comments for the other message entries above.

Appears once on startup, probably simply requires a sleep after tf::TransformListener initialization (for filling the buffer):

Node: /scan_unifier
Time: 16:05:39.612337463 (2016-03-04)
Severity: Error
Published Topics: /rosout, /scan_unified

Lookup would require extrapolation into the past.  Requested time 1457103936.557201524 but the earliest data is at time 1457103937.074180613, when looking up transform from frame [base_laser_front_link] to frame [base_link]

Location:
/u/fxm/git/care-o-bot/src/cob_driver/cob_scan_unifier/src/scan_unifier_node.cpp:LaserScan scan_unifier_node::unifieLaserScans:252

Also, unifieLaserScans should be unifyLaserScans 😉

motivated by discussion ipa320/care-o-bot#42 (comment)

The ROS release system does not support python-pip dependencies...thus, we cannot release cob_mimic with a dependency on python-vlc-pip.
We should implement cob_mimic in C++ using libvlc-dev which is provided by apt which is supported by the ROS release system.

@ipa-josh: we tested your modifications successfully on cob4-1 with hydro. We can display a single laser message in rviz.

But running the laser scanners together with other ROS nodes the timestamps don't fit together. the sick timestamp is ~55061077 sec in the past. Looking at the code there's some strange timestamp handling. Can you please clarify or fix to the current ROS timestamp.

see discussion https://github.com/ipa320/cob_driver/pull/317#discussion_r104105947

testseta

and add it to cob_bringup

in cob_sick_s300, the baud rate parameter does not end up being used, it is forced to 500000. the patch below removes that, and also allows you to use any baud rate rather than just a few (baud rate is just passed through to SerialIO code as an integer). let me know if you prefer a pull request.

diff --git a/cob_sick_s300/common/include/cob_sick_s300/LaserScannerConfiguration.hpp b/cob_sick_s300/common/include/cob_sick_s300/LaserScannerConfiguration.hpp
index 5403817..3883dff 100644
--- a/cob_sick_s300/common/include/cob_sick_s300/LaserScannerConfiguration.hpp
+++ b/cob_sick_s300/common/include/cob_sick_s300/LaserScannerConfiguration.hpp
@@ -13,15 +13,6 @@
 #include "cob_sick_s300/Units.hpp"
 namespace brics_oodl {

-enum baud_rate {
-  BAUD_9600,
-  BAUD_19200,
-  BAUD_38400,
-  BAUD_115200,
-  BAUD_500K,
-  BAUD_UNKNOWN
-
-};
 /**
  * \brief 
  *
@@ -61,7 +52,7 @@ class LaserScannerConfiguration {

     quantity<length> maxRangeDistance;

-    baud_rate baud;
+    unsigned int baud;

     std::string devicePath;

diff --git a/cob_sick_s300/common/src/ScannerSickS300.cpp b/cob_sick_s300/common/src/ScannerSickS300.cpp
index 35b579d..4356615 100644
--- a/cob_sick_s300/common/src/ScannerSickS300.cpp
+++ b/cob_sick_s300/common/src/ScannerSickS300.cpp
@@ -134,9 +134,6 @@ bool ScannerSickS300::open(const char* pcPort, int iBaudRate, int iScanId=7)
 {
     int bRetSerial;

-   // for Care-O-bot3 S300 is set fixed to 500kBaud
-   if (iBaudRate != 500000)
-       return false;

    // update scan id (id=8 for slave scanner, else 7)
    m_iScanId = iScanId;
diff --git a/cob_sick_s300/common/src/SickS300.cpp b/cob_sick_s300/common/src/SickS300.cpp
index 870ff51..909aac4 100644
--- a/cob_sick_s300/common/src/SickS300.cpp
+++ b/cob_sick_s300/common/src/SickS300.cpp
@@ -62,33 +62,9 @@ bool SickS300::open(Errors& error) {

   }

-  unsigned int desired_baud = 500000;
-
-  switch (this->config->baud) {
-    case BAUD_9600:
-      desired_baud = 9600;
-      LOG(trace) << "using 9600 baut to comunicate to Sick S300";
-      break;
-    case BAUD_19200:
-      desired_baud = 19200;
-      LOG(trace) << "using 19200 baut to comunicate to Sick S300";
-      break;
-    case BAUD_38400:
-      desired_baud = 38400;
-      LOG(trace) << "using 38400 baut to comunicate to Sick S300";
-      break;
-    case BAUD_115200:
-      desired_baud = 115200;
-      LOG(trace) << "using 115200 baut to comunicate to Sick S300";
-      break;
-    case BAUD_500K:
-      desired_baud = 500000;
-      LOG(trace) << "using 500000 baut to comunicate to Sick S300";
-      break;
-    case BAUD_UNKNOWN:
-      desired_baud = 0;
-      break;
-  }
+  unsigned int desired_baud = config->baud;
+  LOG(trace) << "using " << desired_baud << " to communicate with Sick S300";
+

   //Initialize the Sick S300
   try {
diff --git a/cob_sick_s300/ros/src/cob_sick_s300.cpp b/cob_sick_s300/ros/src/cob_sick_s300.cpp
index f37aa2d..9e9444b 100644
--- a/cob_sick_s300/ros/src/cob_sick_s300.cpp
+++ b/cob_sick_s300/ros/src/cob_sick_s300.cpp
@@ -276,24 +276,7 @@ int main(int argc, char** argv)
    config.devicePath = nodeClass.port.c_str(); // Device path of the Sick S300
    config.scannerID = nodeClass.scan_id;

-   switch (nodeClass.baud) {
-   case 9600:
-       config.baud = brics_oodl::BAUD_9600;
-       break;
-   case 38400:
-       config.baud = brics_oodl::BAUD_38400;
-       break;
-   case 115200:
-       config.baud = brics_oodl::BAUD_115200;
-       break;
-       break;
-   case 500000:
-       config.baud = brics_oodl::BAUD_500K;
-       break;
-   default:
-       config.baud = brics_oodl::BAUD_UNKNOWN;
-       break;
-   }
+   config.baud = nodeClass.baud;

    if (!sickS300.setConfiguration(config, errors)) {

@ipa-josh
@ipa-mig

When using the published scan topics of "cob_sick_s300.cpp" in each message there are 5 distance values (10 Byte) missing.
The above mentioned class is based on the sick S300 driver (e. g. "TelegramS300.h") that reads the telegrams sent by the S300.
One part of this telegram contains the distance values. In "TelegramS300.h" (size_t num_points) the length of these values inside the telegram is calculated.
https://github.com/ipa320/cob_driver/blob/95e4bf0525cb13630fa768fd6394357d9423052f/cob_sick_s300/common/include/cob_sick_s300/TelegramS300.h#L313-L327

Note: Values at the end of each line in Byte except the tc1_.size in 16 bit words.
should be 1082!
//std::cout << "num_points: " << num_points << std::endl; // 1072
/*std::cout << "--------------- start ------------------" << std::endl
<< "tc1_.size: " << tc1_.size << std::endl // 552
<< "sizeof(tc1_): " << sizeof(tc1_) << std::endl // 10
<< "sizeof(tc2_): " << sizeof(tc2_) << std::endl // 10
<< "sizeof(tc3_): " << sizeof(tc3_) << std::endl // 2
<< "sizeof(td_): " << sizeof(td_) << std::endl // 2
<< "sizeof(TELEGRAM_TAIL): " << sizeof(TELEGRAM_TAIL) << std::endl// 2
<< "JUNK_SIZE: " << JUNK_SIZE << std::endl // 4
<< "last_offset_: " << last_offset_ << std::endl // -10
<< "--------------- end ------------------" << std::endl;
*/

Telegram example:

=> "last_offset" (-10 Byte) is not needed
10 Byte data is missing!

I could not figure out why last_offset is set to -10 when telegram version is 0102.
https://github.com/ipa320/cob_driver/blob/95e4bf0525cb13630fa768fd6394357d9423052f/cob_sick_s300/common/include/cob_sick_s300/TelegramS300.h#L243-L244

S3000/S300 Expert telegram listing documentation does not tell anything about an offset or something similar.
S3000_S300_Expert_2.10_telegram_listing.pdf

Testing with "last_offset" set to 0 (hardcoded) solves this issue, the scan topic now publishes all the data in full length with reasonable values.

if no cepstral voice is installed, cob_sound returns success=false but with an empty error message. Should be filled with no cepstral voice installed

Hello!

When I'm trying to compile hydro version from branch 'hydro_dev' I'm getting following error:

In file included from /home/stogl/Workspace/care-o-bot_hydro_catkin/src/cob_driver/cob_collision_velocity_filter/src/cob_collision_velocity_filter.cpp:50:0:
/home/stogl/Workspace/care-o-bot_hydro_catkin/src/cob_driver/cob_collision_velocity_filter/include/cob_collision_velocity_filter.h:80:73: schwerwiegender Fehler: cob_collision_velocity_filter/CollisionVelocityFilterConfig.h: Datei oder Verzeichnis nicht gefunden
Kompilierung beendet.

I'm not getting this part (and error too) because there doesn't exist CollisionVelocityFilterConfig.h in any branch...

Hi,

There are python scripts to record and generate the configuration params for the battery_voltage_monitor. We are searching more information information on how to use them properly.

To recored:
cob_voltage_control/.../record_current_and_voltage.py

To generate savitzky_golay config params from recorded voltages:
cob_voltage_control/.../time_volt.py

The generated file then goes here (for example cob3-6):
cob_hardware_config/cob3-6/.../battery_voltage_filter.yaml

We have generated some of the values, on our fork for cob3-1:
cob_hardware_config/cob3-1/.../battery_voltage_filter.yaml

The scripts didn't work out of the box, after some small modifications (pull request to come later) we were able to generate some values (above). We only recorded the voltage for 6 minutes after unplugging the robot from the charger as an initial test.

• How long should we record voltage data?
• Under what conditions should we record the data?
  • From fully charged state?
  • During operation?
  • Under heavy loads?

the resolution and rotation of the mimic is wrong and can not be configured using the cpp library for vlc

the service call rosservice call /sound/mute only mutes the service interface, the action interface still produces output

diagnostics is only published once at the beginning but should be published with approx. 1Hz

If we call the mute service during say/play action/service is active the sound output will not mute. Only the next action/service call is rejected if mute is active.

Calling mute should cancel active action or service.

@fmessmer FYI

@ipa-rmb @ipa-jcl

From @ipa-bnm on September 17, 2015 12:5

scan unifier produce gap on the back of cob4-2

@ipa-frm @ipa-mig @fmessmer FYI

Copied from original issue: ipa320/cob_navigation#53

I had some issues with two sick S300 Professional on my robot and could not get the scans to overlap even after calibrating the lidars realtive to robot center. As it was not caused by some offsets in the lidars pose, I started checking the what the lidar driver was delivering. I also found another S300 driver that delivered a slightly different scan while observing the same thing. This motivated me to look more into this problem. I found out that the scans I get using your driver have an angle increment of slightly more than 0.5 degrees and is computed from angle_start, angle_stop and size of the scan array, while the angle increment in the other driver I tested was explicitly set to 0.5, number that is stated in the data sheet of the Sick S300.
In order to get my IPA Sick driver to deliver a similar signal to the other driver, I had to change this file and set the "- 1" in line 264 to "+ 4". I am still not sure about the reason why it works this way but now the increment computed is equal to 0.5 degrees and the extrinsic calibration works and the front and rear laser are overlapping. Can you please take a look into this?

running mimic there are the following errors

• can hardly be killed by ctrl-c
• service call freeces sometimes
• throws contiuously the following errors:

Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fd5b4001248] main vout display error: Failed to resize display
Mimic: happy
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
[0x7fd5d0c16818] idummy demux: command `quit'
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
[0x9d5058] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
"sni-qt/13595" WARN  20:58:48.124 void StatusNotifierItemFactory::connectToSnw() Invalid interface to SNW_SERVICE 
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fc3c4001248] main vout display error: Failed to resize display
[0x7fc3c4001248] main vout display error: Failed to resize display
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fc3c4001248] main vout display error: Failed to resize display
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fc3c4001248] main vout display error: Failed to resize display
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fc3c4001248] main vout display error: Failed to resize display
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fc3c4001248] main vout display error: Failed to resize display
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fc3c4001248] main vout display error: Failed to resize display
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fc3c4001248] main vout display error: Failed to resize display
[0x7fc3c4001248] main vout display error: Failed to resize display
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fc3c4001248] main vout display error: Failed to resize display
Mimic: laughing
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fc3c4001248] main vout display error: Failed to resize display
[0x7fc3d8c04ae8] idummy demux: command `quit'
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
[0xa8e058] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
"sni-qt/13817" WARN  20:59:25.898 void StatusNotifierItemFactory::connectToSnw() Invalid interface to SNW_SERVICE 
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fd7c0001248] main vout display error: Failed to resize display
[0x7fd7c0001248] main vout display error: Failed to resize display
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fd7c0001248] main vout display error: Failed to resize display
Mimic: busy
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
[0x7fd7c0001248] main vout display error: Failed to resize display
Mimic: confused
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
[0x7fd7e0d90f18] idummy demux: command `quit'
VLC media player 2.1.4 Rincewind (revision 2.1.4-0-g2a072be)
[0xadd058] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
"sni-qt/13917" WARN  20:59:42.305 void StatusNotifierItemFactory::connectToSnw() Invalid interface to SNW_SERVICE 
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"
Fontconfig warning: FcPattern object size does not accept value "0"

This issue should be used to remember bringing PullRequests into Hydro that have only been tested for Groovy so far

@ipa-fmw
@ipa-nhg
@ipa-fxm

The base_drive_chain diagnostics message is published with 100Hz. This is not necessary and should be reduced. I think every half second or second is absolutely enough and could be easily done with a simple ros timer.
@ipa-mig What do you think?

It appears that the cob_sick_s300 node loads parameters from the global namespace, rather than a private namespace. This makes it tricky to use multiple drivers simultaneously. I have resorted to launching the nodes in a group namespace using the group tag, i.e.

<group ns="front">
  <node pkg="cob_sick_s300" type="cob_sick_s300" name="front_laser" />
</group>

so that parameters like port can be specified in the front namespace

I have used versions of this driver in the past which did not require this namespace trickery, so I'm not sure why the change was made.

@fmessmer FYI