Vehicle with multiple DUNE instances

[Torsten Teubler]

Hi,

I am currently working on a joint research project developing an AUV.
In the project we use DUNE as control software for the AUV.
Our AUV is equipped with several embedded Linux machines connected via a switched Ethernet network.
Each machine runs a DUNE instance.
One DUNE instance is responsible for the low level control of the AUV whereas the other instances read sensor values and publish them via IMC.
Is a setup with multiple instances for one vehicle currently possible with DUNE?
I haven't found any reference in that direction.

My idea is to implement a "Transport task" (like the UDP Transport) which alters the address related fields in the messages and then put the messages on the IMC bus.
I wonder if there is there a better solution?

Regards,

Torsten

[José Braga]

Dear Torsten,

We have a similar (albeit different in a key aspect) setup to what you describe in systems with auxiliary CPU.

Take for instance the vehicle "lauv-seacon-1" which has 1 configuration file per CPU:
 -https://github.com/LSTS/dune/blob/master/etc/lauv-seacon-1.ini
 -https://github.com/LSTS/dune/blob/master/etc/lauv-seacon-1-aux.ini

In this case we use a TCP connection (Transports.TCP) to exchange data between the two CPUs.

The issue here is that it is only one auxiliary DUNE instance. This DUNE instance has its own FTP server to access data (in this case, just Photos).

The auxiliary DUNE instance does not measure anything, it just takes photos and saves them on a disc.

All messages that are sent by the auxiliary CPU are stored in the main DUNE log file:

This includes Heartbeat, LoggingControl, PowerChannelControl, EntityActivationState and EntityInfo. 

All of these messages will retain their "source address", which is the IMC address of the second CPU.

The source entity addresses will be the ones generated in the second CPU, which will not map to the source entity addresses on the main CPU.

There are a few possibilities here:

1. Data is transmitted to a single sink: each DUNE instance needs its own IMC address so that you can identify the source of the messages by it's source address.
   
• With this solution you have to turn off local logging in all auxiliary CPUs
• You have to transmit data to the CPU that is logging
• You will have to visualize data using 'source', which may get confusing and Neptus MRA (our software) is not suited to handle it like it handles different source entities.
• Only announce the main CPU in the network
• If one sensor outputs more than once the same property you are forced to generate dedicated source entity addresses so that you can differentiate in the main cpu.
• If there are clock drifts, the timestamps won't match unless you regenerate messages locally - which is probably cumbersome
2. Data is handled locally and stored in a local CPU
• In this case nothing is transmitted and data (science) is stored in individual log files per DUNE instance.
• You can modify log filenames so that you can gather all files together
• Either have FTP servers or download everything manually.
• Drawback: clock drifts that you can only solve by synchronizing all clocks at the beginning.

Probably someone else can add more to the discussion (or correct me) but this is my take so far.

Can you describe in more detail the setup you need?

Our architecture is a single CPU that uses the interfaces available to connect to all sensors. The auxiliary CPU is used when we have process intensive tasks - like disk writing/reading for lots of photos.

Best regards,

José Braga

--
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchai...@googlegroups.com.
Visit this group at http://groups.google.com/group/lsts-toolchain.
To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/eb9795b6-4709-41f5-94ab-fd1923354fbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.