LCM support wanted?

[tbeu]

LCM is for Lightweight Communications and Marshalling. The communication is based on UDP multicast and alternatively supports logfile or memory queue for testing. The LCM protocol is used in robotics by several research institutes, see http://lcm-proj.github.io.

I tested the LCM C library on Windows. The integration of LCM within Modelica, especially M_DD, would be straightforward and similar as UDP or CAN (with one additional library dependency on lib lcm that would need to be part of the M_DD distribution).

The marshalling part of LCM is not possible to use within a Modelica environment (since it is not a nominal type system). Thus the SerialPackager has to be reused for encoding/decoding of the data buffer. Endianess needs to be considered again (as is the case for UDP already).

@bernhard-thiele Please comment if it's alright for you to have support of the LCM protocol in M_DD. I will provide a PR once I am ready then.

[bernhard-thiele]

Sorry for the late answer, I was away from email etc.

I just scanned over the website and it sounds interesting. If LCM can be supported in a user convenient manner, it would be nice to have it in M_DD. From a first superficial look, LCM seems a bit similar to the Google protocol buffers (https://github.com/google/protobuf), but probably LCM is more optimized for real-time applications.

How are you going to map the LCM data type generation to Modelica (lcm-gen ...)? From above I assume that you would create the packages manually by using the SerialPackager. That seems a bit error-prone for the user. Or do you think of writing code that understands the *.lcm message definitions and generates Modelica code?

Another question is how to map the event based subscriber model to Modelica. It is not obvious to me what the best way of doing this would be. The example at the website shows that lcm_handle is called periodically and calls out to a function handler to deal with the message.

In summary: It would be nice to have LCM support, though it is not so clear to me how the "look" and "feel" of such a support in M_DD would be. Fine for me to give it a try and help testing/supporting the code under Linux.

[tbeu]

The lcmgen step is some kind of optional preprocessing once the protocol is defined. It needs to be done once for each kind of application. I do not think that it is possible to use the data strcutures defined by *.lcm or the lcmgen-generated headers in Modelica. Which means the LCM analysis tools are not really useful for this kind of Modelica applications interfacing LCM.

I was thinking of supporting the generic functions lcm_publish and lcm_subscribe and let the SerialPackager of M_DD do the buffer handling. This indeed might be error-prone for the user. It also might be possible that the SerialPackger writes a *.lcm file for the used protocol once during simulation runtime such that the user get's some feedback what the protocol is. The generated *.lcm file still can be used with LCM tools then.

Instead of sampled communication (like UDP or other blocks of M_DD) the LCM blocks could work with continuous time, i.e. lcm_handle will be called in each solver step. Once a new message is available the SerialPacker will get this data, however it is eventless in sense of Modelica. This would be different to the existing communication blocks of M_DD.

I will try to implement it but it may take same days or weeks. I got drone.io running for the x64 build of liblcm.a but I am still failing with cross-compilation for x64_86, see https://drone.io/github.com/tbeu/lcm/admin. Maybe @dietmarw has an idea why glib:i386 fails on Ubuntu 12.04. You are now admin of this project at drone.io, too.

[tbeu]

@ashuang FYI.

[dietmarw]

@tbeu You probably want to take a look at https://circleci.com which provides also support for artifacts AND a more modern building environment.

[tbeu]

LCM support is now added to new branch lcm. @bernhard-thiele Please check.

What's left to do:

• Adapt some CMake files for e.g. test_MDDLCM and ITI_MDDLCMWrapper. It takes me 3 min to set up the VS projects but 3 days for the CMake files. Thus, I do not feel in the mood for it.
• Add new test_MDDLCM to drone.io and Travis CI once CMake is adapted.
• Add LCM to the GitHub project description.

[tbeu]

@bernhard-thiele Did you have some minutes to check the new branch?

[bernhard-thiele]

Yes, I will check it later today.

[bernhard-thiele]

Had problems to build the example model (Examples.TestSerialPackager_LCM). Building the example model with Dymola on 64 bit Ubuntu 14.04 I needed to use the library dependencies {"pthread", "glib-2.0", "lcm"} and create the symlink ln -s libgthread-2.0.so.0 libgthread-2.0.so within the directory /usr/lib/i386-linux-gnu. By default Dymola builds 32 bit binaries, so we need to ensure that the 32 bit libraries of glib-2.0 and others are installed.

Now the model builds, but does not yet run. I get the error

The following error was detected at time: 0
MDDLCM.h: Could not allocate LCM object for network provider "udpm://"

Too late and to tired for looking into that now.

[tbeu]

1. As I wrote in the commit message liblcm on Linux requires libgthread-2.0 and libglib-2.0 as system dependency. I wonder why it worked with libpthread for you. For Windows I compiled lcm.dll w/o explicit dependency on glib/gthread, i.e., the required dependencies are statically included in lcm.dll. It would be nice if we could do the same for Linux. @bernhard-thiele, @dietmarw , @sjoelund Do you have an idea how to not use a shared object but rather include the dependent libs?

2. The run-time error is due to lcm_create returning NULL which is strange. I debugged it (on Windows) many times and could not see any problem with it. The lcm project comes with some tests. You could try these tests of the C interface and check them on Linux.

[sjoelund]

@tbeu choosing to link XXX statically is just -Wl,-Bstatic -lXXX -Wl,-Bdynamic. This won't work in a Library annotation I think, and as far as I know if cmake is used it is a bit tricky to get it right, but it can be done.

[bernhard-thiele]

@tbeu Maybe my firewall is responsible for the run-time error. Just had a quick test using the project examples which suggests that (it worked after deactivating the firewall). Need to look into this and also should play with the library dependencies if I find some time in the evening.

[bernhard-thiele]

It is a bit difficult to find time in the moment, it is not forgotten and I hope there is some more time next week.