simple_message header changes

[GoogleCodeExporter]

I have attached a patch which should make extending simple_messages actually 
possible.  Basically, I have added a few more compile definitions which 
separate honest MOTOPLUS and ROS header definitions from their real 
functionality.  I couldn't use them, as-is, because I had to define one or the 
other for the includes to work, but they both had libraries that don't exist on 
the Universal control box.  Here should be a list of all of the new/existing 
compile definitions:

    FLATHEADERS - If defined, it removes the "simple_message" prefix.  The MotoPlus controller should define this, but not ROS.
    LINUXSOCKETS - If defined, uses the basic Linux sockets for communication.  ROS should define this, Motoplus should not.
    ROS - Only used in places where the "ros/ros.h" header is, I think.  Used in the logging file.
    MOTOPLUS - Only used in places where the "motoplus.h" header is, I think.  Used for the logging and communication changes.
    STDIOLOG - Used in the logger to enable the "printf" logging which had been disabled in the MOTOPLUS definition block.  Shouldn't be defined on either ROS or MotoPlus.
    FLOAT64, INT32, INT64 - Used to enable 64-bit floats instead of 32-bit floats.  The documentation for the shared_types file isn't really accurate.  The architecture of the machine (32bit/64bit) doesn't determine the float/int size, it's the compiler/system.  I have included these flags so that you can manually define the size of the floats and ints in shared_types.  If you don't define any of these flags, it reverts to the previous behavior.

This patch is based on revision r1349, so it should be fairly up to date.  If 
someone can add the FLATHEADERS compiler definition to the MotoPlus controller 
and test my changes, we'll be one step towards making simple_messages more 
portable.

-Kelsey

Original issue reported on code.google.com by kphawk...@gmail.com on 21 May 2013 at 8:22

Attachments:

• simple_message_fix_headers_kelsey.diff

[GoogleCodeExporter]

One comment.  There are other packages including industrial_robot_client which 
need the LINUXSOCKETS flag added to the CMakeLists.txt.  I'd like to leave it 
to whoever will be incorporating these changes to update the necessary 
CMakeLists, or propose a better solution (possibly defining the flag wherever 
needed based on the ROS flag).

Original comment by kphawk...@gmail.com on 22 May 2013 at 10:58

[GoogleCodeExporter]

Apparently I wasn't able to wrap every header appropriately.  The attached 
patch should fix that problem.  I was able to get it to compile without the ROS 
flag activated.

Original comment by kphawk...@gmail.com on 22 May 2013 at 11:19

Attachments:

• simple_message_fix_headers2_kelsey.diff

[GoogleCodeExporter]

In the latest patch, message manager.cpp has the following macro logic:

#ifdef ROS
#include "ros/ros.h"
#else
#include "unistd.h"
#endif

The #else will fail under motoplus because unistd.h is not a valid header.  Is 
this header needed for the universal?  What in the message manager requires 
this header?

Original comment by shaun.ed...@gmail.com on 26 May 2013 at 1:13

[GoogleCodeExporter]

The check-in of this patch (r1361) almost certainly broke the dx/fs100 motoman 
packages.  Assigning this to me to fix when I get access to the motoplus 
application.

Original comment by shaun.ed...@gmail.com on 26 May 2013 at 1:56

[GoogleCodeExporter]

There is a sleep function included in this file.  If using the ros.h header, it 
gets included automatically.  If not, you have to include unistd.h  To get this 
to work with the MOTOPLUS stuff, I believe it it should be changed to:

#ifdef ROS
#include "ros/ros.h"
#elif !defined(MOTOPLUS)
#include "unistd.h"
#endif

Original comment by kphawk...@gmail.com on 26 May 2013 at 6:31

[GoogleCodeExporter]

Below the MOTOPLUS include in the file log_wrapper.h, you must add the 
following macro definition:

#ifdef STDIOLOG
#include "stdio.h"
#endif

Original comment by kphawk...@gmail.com on 27 May 2013 at 6:56

[GoogleCodeExporter]

The makeConnect method is also blocking if no connection is available.  This 
can be subverted again by only calling the method if the isReadyReceive(0) 
method returns true.

Original comment by kphawk...@gmail.com on 27 May 2013 at 7:13

[GoogleCodeExporter]

Kelsey,

We have to be careful about preserving backwards compatibility if at all
possible.

I'm assuming you have a use case in mind where makeConnect should not be
blocking?

Also, If you are comfortable with using catkin and rosbuild together, I can
now give you access to the github repo.  You can make these changes on a
branch and then we can use a pull request to review them and merge them
in.

Original comment by shaun.ed...@gmail.com on 27 May 2013 at 7:23

[GoogleCodeExporter]

>I'm assuming you have a use case in mind where makeConnect should not be
blocking?
The Universal controller doesn't seem to allow threading in it's controller or 
any form of blocking in the realtime loop.  Thus, once the controller starts, 
it has to send at least an empty command at 125 Hz or the controller forcefully 
exits and the robot shuts down.  Thus, every command I call once the controller 
starts must be non-blocking.  Since I would prefer that the UR controller run 
regardless of whether there is an established connection, I'd prefer to be able 
to make the connection to a client after the controller is in its realtime loop.

Futhermore, there is code in joint_trajectory_streamer.cpp:150-153 which 
appears to wait after calling makeConnect, so there seems to be a disconnect 
somewhere.

>Also, If you are comfortable with using catkin and rosbuild together, I can
now give you access to the github repo.

That would probably work better.

Original comment by kphawk...@gmail.com on 27 May 2013 at 7:33

[GoogleCodeExporter]

Kelsey,

Just an FYI...I tried the make connect on my side and it returns
immediately with a failure code on the client side.  I assume you are using
the server side.  The difference between client server behavior, might
explain the difference you seen in the joint_trajectory_streamer class.

Original comment by shaun.ed...@gmail.com on 28 May 2013 at 3:36

[GoogleCodeExporter]

Kelsey,

What do you mean by "The Universal controller doesn't seem to allow threading 
in it's controller"?
I've got threads working fine without any magic or anything.

I've attached my very simple controller I used for generating the data showed 
at ROSCon. It has several drawbacks (I.e. if the client disconnects the program 
hangs), and the control loop should definitely be moved out of the main 
function, but it shows how to implement threads.

Original comment by thomas.t...@gmail.com on 29 May 2013 at 9:42

Attachments:

• example_robotcomm.c

[GoogleCodeExporter]

I believe I tried using threading at some point, but found that the driver was 
crashing sporadically (it may have been something else, but this was my guess). 
 The UR control box is running a realtime version of Linux, which suggests to 
me that all threads are always preemptable.  What happens when you call 
"robotinterface_send" is a mystery, but it seems like doing anything while that 
command is executing is probably discouraged.  Furthermore, if all you're doing 
is relaying commands and data from an external, higher-level controller, then 
you should be able to accomplish everything synchronously, no problem.

Original comment by kphawk...@gmail.com on 3 Jun 2013 at 6:26