OpenICE not working offline on Ubuntu

Rado-

We recenting did some testing using offline Beaglebones and ran into a problem with DDS requiring a timestamp.  Not sure if this is related but, like you, we are hoping to avoid internet connections. 

Alistair 

Hi Allistair,

Thanks for the reply. If you got to that point, then presumably you were at least able to start openICE? What version of ubuntu and java are you using?

Thanks,
Rado

Hi everyone,

To provide some further information.  The only OMG standard protocol for DDS communication is RTPS/DDSI and the only "Platform Specific Module" for RTPS that has been ratified for RTPS is over UDP/IP.  Some vendors, including RTI, do offer proprietary transports using shared memory.  We disable this transport in our DDS build to maintain inter-vendor compatibility but if you'd like to create your own build and experiment with that transport then please do. More info here.  I'd love to hear how it works out.  Also I haven't had much success using the local loopback adapter but that can also be further explored if you'd like.  We can contact RTI for further information.  For the RTI implementation we are using all these settings are rolled up into the XML QoS configuration.  There's reference material on configuring the RTPS (UDPv4) transport available here.  In principle the loopback can be used but I haven't personally had a lot of success with it.

Regarding clocks we were talking just this morning about this in the lab.  This is a rich and complex issue.  DDS specifies a source_timestamp for each sample indicating when it was written into the Writer.  In the past we have examined this value to gauge the time related to a sample but we are moving away from that in favor of specifying timestamps within our domain specific model.  The reason being that these source_timestamp values should remain a detail of the middleware.  In fact DDS can be configured to use a monotonic clock where the source_timestamp values are no longer populated from the realtime clock.  More information on clock selection here.

Adding insult to injury in our QoS settings we are asking DDS to guarantee that samples are delivered in the order they were emitted at the source per the DesinationOrderQos.  This means that DDS cannot allow samples to be written on the sending side out of time order.  As a consequence a dramatic change in realtime clock values causes failures to "write" samples.  This means we must at least 1.) ensure that ntp clock adjustments will not exceed source_timestamp_tolerance and at most 2.) consider switching to monotonic clocks across the board.  In this way big shifts in the RTC won't interfere with the middleware layer.  Alternatively we could change the system to use the default "BY_RECEPTION" DestinationOrderQos but we'll need to document it heavily that anyone consuming the data must cope with the possibility (even if remote as a practical matter) of data being delivered to a reader in a different order than it was written to the writer.

All that said to assign wall clock time to data from a medical device that emits no time markers (or too-low resolution time markers) requires an adapter with its clock set.  For an embedded device (like a beaglebone) without connectivity to the internet at large you could try setting up a local host as NTP server.  We're also going to experiment with battery-backed RTC add-ons for our beaglebones and we'll report back on our experiences.  Another critical need for some absolute synchronized time is the need to correctly interleave data after the fact.  To meet that requirement we demand that participants all have the means to attach meaningful realtime clock values to data.  This as opposed to a potentially more complex solution in the spirit of Lamport.

I hope this information is helpful. I'm excited to be engaged in this discussion and welcome more feedback as we continue o evolve OpenICE.

Thank you
Jeff Plourde

Hi Jeff,

Thank you for the explanation. I believe we have a different problem, though, and hopefully simpler.

I'm pretty sure we have a compilation issue because we can get our laptops running Windows or Mac to connect to devices even when offline. But on Ubuntu it just crashes when there's no internet connection (even if we just use a laptop). As far as I understand, this is a problem with the spring framework of gradle where for some reason under ubuntu it goes online every time to download some beans schema. This may also be an eclipse-gradle bug under ubuntu (and may also be a java problem). So I was hoping you guys may have encountered this problem before or have some insight.

As for the problem you describe, for now we will solve it by collecting data locally on each board, since the devices we are interested in already provide enough measurements. We will worry about interoperability issues once we get this first step working smoothly.

Thanks,
Rado

To make this even more confusing, I can't even run demo-apps with a simulated device with no internet on ubuntu. So it's not a compilation problem.

Hey Rado,

I just reproduced this - you are absolutely right. Ubuntu without an internet connection will fail. This is a spring configuration error with how the application tries to locate XML schemas on the web. It's in the queue to be fixed ASAP.

Sorry for the inconvenience. And THANK YOU for helping by bringing errors like this our attention. We have a small team and limited resources to test everything everywhere at the pace we're moving. Every bit of help is appreciated.
Jeff

Sure, no problem. Please let me know when you guys fix this.

Thanks,
Rado

Hi Rado,

We are trying to reproduce the problems you are having. With respect to the XML related error it would be helpful to know the classpath with which you are launching the program. Is it derived from the gradle dependency tree?

Thank you
Jeff

So, I run it using eclipse, and the classpath is whatever eclipse produces. Do you want to me paste the classpath from eclipse here?

I was actually looking at the classpaths yesterday. Under windows, where everything is fine, all the schemas are added to the eclipse classpath, whereas under ubuntu they just remain in some jars in a gradle dependency folder, which is never used, I'm guessing.

Rado

Hi everyone!

What's about this issue? How can I run OpenICE without internet connection?

I have this error:

2015-08-16 20:20:47,859|WARN|XmlBeanDefinitionReader.warning:48|Ignored XML validation warning|OpenICE-Main|139877|

Thank you so much!

Hi Adrian,

As far as I know, it is not possible to use the current version of OpenICE on Ubuntu offline. Based on a conversation I had with Jeff in one of the other threads, the spring schemas are looking for a network connection (could be a local connection, not necessarily an internet connection).

The way I see it, there are two ways to proceed (unless OpenICE is somehow modified). The first is to strip down the OpenICE code so that it doesn't include the networking stuff. The downside here is that you'll have to do this every time OpenICE is updated.

The other option (I'm speculating here) is to try to simulate an open connection and see if that works. I haven't had time to try these things but we'll eventually get a Master's student to try.

Thanks,
Rado

Ok, thank you Rado.

I will try the second option.

Regards!

Hi Adrian and Rado,

This is still an open issue unfortunately. As Rado said, Spring will try and use any network connection before proceeding. A work around is to have any network interface up when building. Even if Spring can't reach the web, simply providing an up interface for it to check will allow the build to proceed.

I will let you know when this is fixed as it is not an intended use. Sorry for the inconvenience,
Jeff