How to display custom 3D models in the 3D Viewer

The 3D viewer can be used to display a wide variety of 3D primitives (point clouds, lines, triangles, quads, etc...). This tutorial explains how to integrate your own 3D models in the 3D viewer and how to use them in the scene.

Supported object types

The 3D viewer currently only supports four files formats to define custom objects:

  • BSSCFG file format (see displaying a variable number of objects section)
  • JPEG or PNG file formats (used for flat texured walls)
  • Wavefront OBJ file format (used for complex polygonal models)
  • XYZRGB file format (used to represent point clouds)

XYZRGB file format

This is a simple ASCII file format used to represent point clouds. Each line represents a single point. Each line contains six values separated by whitespaces. The first three values indicate the X, Y and Z coordinates of the point in the scene. They are considered as floating point value. The last three values represent the color of the point . They are considered as integer values between 0 and 255.

Displaying a single object

The easiest way to do this is to create an object which uses the File object type. This kind of object supports image files, OBJ files and XYZRGB files.

Displaying a variable number of objects

Several object types in the 3D viewers let you display a variable number of object instances (PointCloud, Lines, Triangles, Quads, etc...). Most of them provide the 3D model geometry on an input of the 3D viewer. Here we want the 3D viewer to use custom models so the only data we want on the input are an object type identifier that we can use to map the object to a 3D model and a 3D transformation to be able to move the object in the scene. To do this, we need to use the RealObjects type.

Starting with the 3D viewer v1.20, creating a RealObjects object let you specify a configuration file. This is where the BSSCFG file format is used. It is a configuration file which lets you associate 3D models (defined with other files) with identifiers.

BSSCFG file format

The BSSCFG file format is a relatively simple ASCII file format. You can find an example in the samples provided with rtmaps_ibeo.pck in RTMaps 4.2.3 (packages/rtmaps_ibeo\samples/3d_models/ibeo_real_objects.bsscfg).

Each line contains an identifier, a 3D model and optionally a 3D transformation. It looks like this:

identifier 1<TAB>3D model 1[<TAB>3D transformation]<LF>

identifier 2<TAB>3D model 2[<TAB>3D transformation]<LF>

identifier 3<TAB>3D model 3[<TAB>3D transformation]<LF>

<TAB> must be replaced with one or more tabulations. <LF> must be replace with an end of line (either \r\n or\n).


It can be either a keyword, an integer values which can be stored in a 32bit integer or a string enclosed in double quotes. The only keyword currently recognized is Default. It lets you specify the 3D model used when no other identifier is valid. Integer identifiers are used for Custom RealObject. The identifier is matched against the userKind field. String identifiers are used to override the model drawn for Vehicles, Signs and Trees. Here is a list of the recognized identifiers:

  • "Vehicle/Car"
  • "Vehicle/Bus"
  • "Vehicle/Truck"
  • "Vehicle/Bike"
  • "Vehicle/Motorcycle"
  • "Sign/Stop"
  • "Sign/Yield"
  • "Sign/OneWay"
  • "Sign/TurnLeft"
  • "Sign/TurnRight"
  • "Sign/SpeedLimit" (default for speed limit signs when limit value is not found)
  • "Sign/SpeedLimit/[limit value]"
  • "Sign/EndOfSpeedLimit" (default for end of speed limit signs when limit value is not found)
  • "Sign/EndOfSpeedLimit/[limit value]"
  • "Sign/TrafficLight/Red"
  • "Sign/TrafficLight/Orange"
  • "Sign/TrafficLight/Green"
  • "Sign/TrafficLight/OrangeBlinking"
  • "Sign/TextOnly" (default for text signs when the text is not recognized)
  • "Sign/TextOnly/[text field of the structure]"
  • "Tree/Cone"
  • "Tree/Round"
  • "Tree/Cylinder"

3D models

It can be a keyword or a path (enclosed in double quotes) to an obj file describing the 3D model. When it is a keyword, it can be either Cube, Pyramid or Sphere and must be followed by 3 floating point values separated by tabulations which indicate the shape color. When it is a path, it must be either relative to the configuration file location or absolute.

3D transformation

This part is optionnal. It is used to normalize the model origin and orientation. Please not that if you want to change the orientation of the object you must also specify the model origin. The origin is decribed by three floating point values (X, Y and Z coordinates) expressed in the 3D model coordinate system. They are separated with tabulations. The orientation is also described with three coefficients. This time they represent euler angles expressed in degrees.

DDS with RTMaps, Simulink and third party applications

This article shows how to use DDS (Data Distribution Service) with RTMaps, third party applications and Simulink. First, we will give a small introduction on DDS. Then, we will discover how to use DDS in RTMaps, how to handle DDS RTMaps types from a third party application and finally how to use DDS to communicate between RTMaps and Simulink.

A short introduction on DDS

The Data Distribution Service for Real-Time Systems (DDS) is an Object Management Group (OMG) machine to machine middleware standard that aims to enable scalable, real-time, dependable, high performance and interoperable data exchanges between publishers and subscribers. DDS is designed to address the needs of applications like autonomous vehicle, financial trading, air traffic control, smart grid management, and other big data applications.


DDS global data space


The main object shared across the network is called a topic. A topic is defined by a 3 elements tuple :

  • name : identify the topic within the domain
  • type : the programming type of the topic. Like a C/C++ structure
  • QoS : a policy that express the non-functionnal properties of this topic (reliability, history, persistence)

A topic instance is called a sample. Those samples are shared through subscribers and publishers. A publisher uses a data writer to produces samples, while subscribers uses data reader to access samples.

To talk to each others, publishers and subscribers must use the same topic, i.e same name, same type and a compatible QoS.

Using DDS with RTMaps

RTMaps is shipped with an OpenSpliceDDS Community version. It is installed in the packages/rtmaps_dds directory of your RTMaps installation. The RTMaps package rtmaps_dds.pck is located there.




Once you have loaded the package, you are able to use the DDSPublisher and DDSSubscriber components.

The DDSPublisher has the following properties:


topic_name : this is the topic name (see before)


Durability : this is a QoS parameter. This could be:

  • VolatileNo need to keep data instances for late joining data readers 
  • Transient localData instance availability for late joining data reader is tied to the data writer availability 
  • TransientData instance availability outlives the data writer 
  • PersistentData instance availability outlives system restarts 

History : this QoS can be set to

  • Keep All : The History QoS can be set so keep all samples produced by the writer and not yet taken, until resource limits are not reached 
  • Keep Last K : The History QoS can be set so to always have the latest K samples 

Note that you don't need to specify a type for the DDSPublisher as it is automatically chosen by RTMaps when the component receives its first data. However, in the DDSSubscriber, you will have to specify a type to build the complete topic. Available types are : Integer32, Integer64, Float32, Float64, Stream8, Text, IplImage, MAPSImage, CANFrame and RealObject.

Using a third party application

You can exchange data with RTMaps and your application by using DDS. To do that, you can use the DDS library shipped with RTMaps, located in the installation folder. Please note that you have a C++ example application that read a DDS topic (RTMaps Float64) and a RTMaps diagram example.


If you want to use that DDS implementation, you will have to compile at least the DDS part with Visual 2010 or 2013. The OpenspliceDDS version used in RTMaps is included in the rtmaps_dds package, for Visual 2010 and 2013. However, you might look at a different version on Prismtech website or contact Prismtech to get the library for your specific platform.


Normally, the example project is clear and documented enough so that the programmer should get rapidly the idea. A few important precisions though :

  • The project contains generated files using idlpp.exe. Those files are located in the src_generated directory, you must add these files to your project. A .bat file is provided to show you the options we used (standalone, mainly).
  • The PATH environment variable has to be modified to load DDS modules (.dll, .so). The libraries are located in the bin directory of the rtmaps_dds folder. Libraries are for example, for Windows : cmsoap.dll, ddsi2.dll, etc.

Example : C:\Program Files (x86)\Intempora\RTMaps 4\packages\rtmaps_dds\lib\VC2013\x64\bin

  • The OSPL_URI environment variable must be set and contain a valid file path to the XML config file (ospl.xml).

Example : file://C:\Program Files (x86)\Intempora\RTMaps 4\packages\rtmaps_dds\etc\config\ospl.xml

  • The OSPL_LOGPATH environment variable must be set and pointing on a read/write location. Please consider using your home directory.

Example : C:\temp

Those environment variables can be set directlty in the Operating System, or directly in the code (see the first lines of the examples). if those environment variables are not correctly set, you will have obscur DDS messages (popup or console) telling you that the DDS Kernel couldn't initialized properly.

Communicating with Simulink

This DDS bridge works with all RTMaps data, including images, but is not compatible with dSPACE prototyping systems. If you plan to use a dSPACE MicroAutoBox or AutoBox, please consider using the RTMaps - Simulink - dSPACE prototyping systems.


To make the DDS bridge work with Simulink, you have to set the 3 environment variables we talked about in the last paragraph : PATH, OSPL_URI and OSPL_LOGPATH. Once this is done, you will be able to use the mexw32 or mexw64 simulink binaries provided by Intempora in the mathworks package to place publisher and subscriber onto the Simulink diagram.

Note : The DDS Simulink bridge requests to have the VC2013 x86 / 64 bin in the PATH (rtmaps_dds\lib\VC2013\x64\bin OR rtmaps_dds\lib\VC2013\x86\bin)


If RTMaps is not installed on the computer where you use Simulink, please also install VC2010  and VC2013 redistributable.

If you need to use a 64 bit Matlab version, then add the 64bit DLLs to the PATH. Otherwise, use the 32 bit ones.

Trouble with DDS ?

You have an error saying that you could not create topic ?

Then you probably already have a topic defined with another type! Please change your topic name, and it shoud be fine.


You can't run a DDS application ? It crashes at the very beginning when you launch your application ? 

Then you probably have a wrong DDS configuration : PATH, OSPL_URI and libraries. Please check it again...

RTMaps - Simulink - dSPACE prototyping systems

This tutorial shows how to interact with Simulink and dSPACE prototyping systems from the RTMaps studio. The goal is to exchange data between RTMaps and Simulink, while staying compatible with dSPACE prototyping systems like dSPACE MicroAutoBox with complete control of data synchronisation.

 rtmaps simulink toolchain



The communication between RTMaps, Simulink and dSPACE prototyping systems is done via UDP sockets over the network. This type of commmunication allows software to be executed on different machines, which is very convenient in many cases. Below are the two diagrams we will describe in this tutorial. Those diagrams are very simple, but demonstrates very well how to realize an application using RTMaps and Simulink. In this example, RTMaps generates a vector of 3 double and sends it to Simulink. Simulink reads the data, multiplies the vector by 10 and sends the modified data back to RTMaps for display.



The RTMaps diagram uses the standard Raw Socket Client configured in UDP mode to read data across the network and also to write to the network (a different port is used for reading and writing). A serialization is needed before sending to the network and a deseralization after receiving from the network. These serialization and deserialization must be done via dedicated components: SimulinkDSpaceDeserialize and SimulinkDSpaceSerialize (available in the rtmaps_mathworks.pck package). Of course, you have to ensure that the configuration in the serialization/deserialization in RTMaps matches the one in Simulink.




On the Simulink side, the model is very similar. To receive data from RTMaps, we have a UDP Receive block. This block has mainly a sample time and a timeout parameters. We will see in the next section how to configure it properly depending on the context.

We also have DSDecode32 and DSEncode32 blocks which respectively decode and encode data. They are configured through a format string which describes the data layout. Here the configuration is [9 9 9] which means the data consists of 3 double precision float numbers. The documentation of the format is written directly in the properties of this block. Here is what you should find:
  • 1: BOOL
  • 2: INT8
  • 3: UINT8
  • 4: INT16
  • 5: UINT16
  • 6: INT32
  • 7: UINT32
  • 8: FLOAT
  • 9: DOUBLE

Note that you can copy/paste this configuration string from RTMaps to Simulink and vice-versa. The two RTMaps components have a dedicated property with the same format as on the respective Simulink and dSPACE blocks where you can copy and paste your configuration. This will automatically create the corresponding inputs or outputs!

Once the data is decoded, you can do whatever you need with the data. Here a very simple operation is performed: we multiply the data by a 10 factor just for demonstration. Then, we encode the data (same configuration as the decoder actually) to prepare them for sending thanks to the UDP Send block.

Working with RTMaps and Simulink

There are two ways to perform time synchronization between RTMaps and Simulink:

1- Simulink is clocked by RTMaps.

This is the communication mode we advise you to use. Much simpler and faster to use with Simulink only. In that mode, Simulink blocks until a fresh new data comes from RTMaps, and then it performs one simulation step. To do so, on the Simulink side, the UDP receiver should be configured with a receive timeout "infinite". In that case, Simulink will wait forever until a data sample comes.
On the RTMaps side, the serializer in RTMaps may be configured in FIFO reader mode or in sampling mode. In sampling mode, RTMaps will send data at regular intervals, whereas in FIFO reader mode ( Synchronized, Asynchronous or Triggered by first input ) RTMaps will send data as soon as new ones are available on its inputs.
As a matter of fact, if you need the Simulink clock and the RTMaps clock to go approximatively at the same speed, then you probably want to set RTMaps in sampling mode and to set the Simulink simulation sample time to be equal to the sample time in RTMaps.

2- Simulink reads as fast as it can

In that mode, Simulink works on its own. The UDP receiver should have a 0 timeout parameter so that it reads and returns immediately at each Simulink step. Because Simulink works as fast as it can, you will probably need to use an "enable subsystem" block and to use the Status output of the UDP Receive block to trigger this subsystem. In this situation, your processing block will execute only when it gets new data.
With this mode, the time in Simulink will go very fast and is not synchronized with RTMaps, and there really might be more CPU consumption too because there is no blocking wait.
As a conclusion, we advise you to use the first method for Simulink only, and prefer using this one for the interface to dSPACE prototyping systems.

Working with RTMaps and dSPACE prototyping systems

Here the goal is to use the dSPACE MicroAutoBox in collaboration with RTMaps. Well, the MicroAutoBox being programmed with Simulink, this is exactly the same as presented before, except that you will have to use dSPACE RTI Ethernet (UDP) Blockset instead of the UDP Send and UDP Receive blocks. Moreover, as the MicroAutoBox is responsible for the control of the time, you can only use the second part of the last section. You may want to configure RTMaps in sampling mode at the same sample rate than the MicroAutoBox. Indeed, if RTMaps send data faster that Simulink can read them, the Simulink buffer will grow and latency will appear in the data.
Lastly, you probably will have to adjust some IP adresses, but that's no big deal.

Triggered recording

As you know, RTMaps allows you to record data, and play it back when you want to. But you can do much more than that. Indeed, the records can be triggered, on demand, in multiple ways. This is very useful in many aspects : reduction of data, reduction of events search, etc...

Manual Trigger

This the simplest way. Just click on the input of the recorder (under the red circle in the next figure). In the I/O section, we have the following properties: trigger, triggerBufferTime, triggerBufferSize, triggerReleaseTime, triggerReleaseSize. Let’s detail what they actually mean.

  • trigger: This boolean property is used dynamically to fire the trigger (when setting it to true) or to release it (when setting it to false). As soon as this property is set to true, RTMaps dumps the memorized data (whose length was specified by the triggerBufferSize or triggerBufferTime properties), and begins recording, until it is explicitly set to false, or until the recording length specified by the triggerReleaseTime or triggerReleaseSize is reached. Be careful when using triggers, since data is stored in the memory of the computer (RAM), and not on hard drive. This may be harmful for performance if the duration of past data you plan to record is too long. The default value is false if any of the following four properties was modified. The default value is true if none of the following four properties was modified. Remark: It is this default value, along with the default values of the following four properties, which makes any record method record forever if no property is modified.
  • triggerBufferTime: Set the triggerBufferTime to the time you want to see recorded before the trigger. This integer property defines the duration of the buffer used to memorize data, while data is not actually recorded. These memorized data will be dumped to disk as soon as the trigger is set. The duration is expressed in milliseconds. The default value is 0, which means that no data is memorized.
  • triggerBufferSize: This integer property defines the size of the buffer used to memorize data, while data is not actually recorded. These memorized data will be dumped to disk as soon as the trigger is set. This size is expressed in number of samples. The default value is 0, which means that no data is memorized. You can choose to specify either the triggerBufferSize or thetriggerBufferTime, their function is the same but with different units.
  • triggerReleaseTime This integer property defines a duration after which a set trigger will be automatically released. The duration is expressed in milliseconds. The default value is 0, which means that the trigger is never released (i.e. the RRM keeps on recording forever).
  • triggerReleaseSize: This integer property defines a size of incoming data after which a set trigger will be automatically released. The duration is expressed in number of samples. The default value is 0, which means that the trigger is never released.

Now we know how triggered recording globally works, let’s assume we want to record a video from a webcam (see diagram below), but only on demand: one second before the trigger, and one second after. To achieve that, we have to set the recorder’s input trigger to false, i.e RecFile_5.Webcam_6.outputMAPSImage.trigger = false, and set the triggerBufferTime and the triggerReleaseTime to 1000 (remember that it’s in milliseconds). Setting the trigger property to true during execution will trigger recording.

Let’s run the diagram. When we are ready, we just tick the trigger box, and the recording starts: it records the next second and keeps the last second in memory. Then it writes the whole sequence to the hard disk.

Use of Condition component

The manual triggering definitely works, but its usage is limited. Indeed, we may want the trigger to be set automatically by a component, or when a value goes over a threshold. In this tutorial, we propose to perform a recording when the acceleration of the x axis of an accelerometer goes over 1 (i.e rapid movement). To do this, we will use the condition component. So let’s add an accelerometer and a condition component to the previous diagram.

Now we have to tune the condition component so that it triggers the recorder when the user shakes the accelerometer. So we enter “acc{0} > 1 && acc{-1} < 1” in the property “Condition” (see Condition component). This immediately creates an input called acc. We can connect this input to a the accelerometer component.

Next we have to tune the condition component so that it sets the trigger to true when the condition is TRUE. All we have to do is to fill “Parse when TRUE” with the following instruction: RecFile_5.Webcam_6.outputMAPSImage.trigger = true
Note that this “code line” is the same line that you can see in the console when you tick or untick the trigger property! This is the real instruction executed by the RTMaps engine.

Finally, let’s run the diagram. When the user does nothing, nothing is recorded. As the user shakes the accelerometer, the recording starts with the parameters we have seen before (1 second before and 1 second after the trigger).
Let’s replay the previous recording. We can see a 2 seconds recording in which the user is shaking the accelerometer (see figure below)!

Timestamp and Time of issue

In this article we cover not only the definition of the timestamp and the time of issue, but also information about the precision of data timestamping.


The Timestamp is the intrinsic date of the sample. It should be as close as possible to the date of occurrence of the real data which the sample corresponds to. It may be supplied by the first component that created the sample (i.e. the acquisition component). The timestamp remains unmodified while the sample goes through the different components of the processing chain. The Timestamp often corresponds to the date where the data is available in system memory for the acquisition component since we do not often know the delay induced by the sensor acquisition, the sensor data transmission. However, if this delay can be known, the Timestamp can be corrected in order to take it into account.

The TimeOfIssue is the date corresponding to the last time the sample was output from a component. Therefore, this date increases as long as the sample runs through the di fferent processing components.


The data timestamping accuracy depends on the data acquisition hardware and the platform RTMaps is running on.

Under Windows, the RTMaps standard clock is based on the performance counter (the CPU cycles counter) which offers an excellent resolution (1 nanosecond for a 1 GHz CPU). Thus, due to the PC architecture, the RTMaps software timestamping after an interruption request (IRQ) signaling data arrival is usually a few tens of microseconds.

Under Linux, the RTMaps standard clock uses the gettimeofday function which offers a microseconds resolution. The RTMaps software timestamping after an interruption request (IRQ) signaling data arrival is also usually a few tens of microseconds.

Usually, the Recorder component only keeps 4 digits after the second, which means a resolution of 100 microseconds is recorded in the RTMaps recordings.

However additional latency can be induced by different factors:

  • sensor acquisition time (for a camera sensor it can be an integration time)
  • sensor preprocessing duration
  • data transmission duration over a bus (analog video, FireWire, USB, Serial ports, Ethernet...)

If such a latency is known (thanks to the knowledge of the electronics system specification), it can be possible to correct the data timestamps inside the RTMaps acquisition components.

Note: the data timestamping accuracy (activated on IRQs which are hardware signals emitted when data arrives to a device) is very good (well bellow the millisecond).
However, the timers have a lower accuracy: timers are used for components that need to pause for a certain duration, or wait for a specific date, or activate a timeout.

Under Windows, RTMaps uses multimedia timers which are the best timers available with a 1 ms resolution.

Under Linux, RTMaps uses RTC based timers which also offer a 1 ms resolution usually (but may be higher for specific distributions or kernel options).

Online / Offline Diagram

In RTMaps, you can open and edit diagrams at demand. But what you may not know is that there are two ways of opening diagrams : online and offline. Let's see what the difference is:

  • Online Diagram (default option) : this is a read / write diagram, which is what you are certainely used to manipulate. Only one online diagram can be opened in RTMaps at a time. A online diagram can be runned normally.
  • Offline Diagram : this is a read only diagram. An offline diagram is just a graphical representation of the real diagram, but you cant' modify anything into it, and you can't run it. Actually the components are not even instantiate, they does not exist at the RTMaps engine level. You can have as many offline diagrams as you want in RTMaps.


Macro components

In RTMaps4 you can create macro components, i.e components that contain components.

Create a macro component

Here is a simple diagram that performs face detection with a webcam, a pattern recognition algorithm, an overlay and an image viewer.

Let's select the two components OpenCV_PatternRecognition_2 and OpenCV_Overlay_3 and right click on them. Consider the following two options in the contextual menu: Generate internal Macro-Component and Generate external Macro-Component. The two methods create a macro component, but there are a few differences between them:

  • An internal macro component is defined only in the current diagram. It can't be used in any other diagram. However, an internal macro component can depend on external macro components.
  • An external macro component can be reused in other diagrams than the one where it was originally created. Of course, external macro components can't depend on an internal macro components (this would make them not exportable).

In both cases you should obtain a diagram like this:

With this macro component (in a new tab):

Note that RTMaps always puts one input per wire in a macro component. So in our case even if the two wires are connected to the same Webcam output, the macro component creates two inputs. As there can be only one input per input alias, you can't wire the input of the pattern recognition to the input_1 alias directly. To achieve that, you will have to use a bypass component.

Now we have only one input to our macro component! Mission accomplished!

If you have closed your macro component or if you want to edit it, you can do a right click on it, then Edit Macro-Component. A new tab will be opened with your macro component inside. Note that until you explicitly save the macro component diagram, its behaviour remains unchanged in the global diagram. Indeed, the save action synchronizes the macro component diagram with the global diagram.

Export properties

After creating a macro component, you may need to tune some properties of the components inside, but repeatedly editing the macro component might become a hassle. Furthermore, you may want to instantiate your macro component multiple times and to set different parameters for every instance. To achieve this, you have the possibility to export properties.

Exporting a property means that a property of a component inside the macro component will become available in the properties of the macro component itself in the global diagram, enabling you to control per-instance (and directly from the global diagram) the relevant parameters pertaining to the inside of a macro component. How can we do that? Well, it's quite easy.

Edit the macro component. Click on the macro component diagram (anywhere but on a component), this will select the macro component global properties. Here is what you should see:

In the Properties tab, click on the "+" button (next to Reset and Apply), this will create an empty entry with two fields:

  • Alias: the name of the macro component property in the global diagram. Choose any name you want, it's just an alias.
  • Target: the real property. Choose the property you want to export.

Select the Target in the combo box, give it an alias, and click on Apply. Save your macro component, and look at your diagram using the macro component: a new property with the alias you have just chosen should have appeared.

Export actions

You can export actions pretty much the same way as you export properties: just select the Actions tab in the Properties view instead of the Properties tab (see screenshot above).

How to synchronize the RTMaps clock to an external clock ?

Each RTMaps component that handles an external clock has a special identifier (cf next figure). It is the blank circle on the upper left of the component.


Just do a right click on that type of component, and click on Set as Main Clock. The standard RTMaps clock will be replaced by this one.

Note that you can change the RTMaps clock anytime by changing the Engine Properties. To do that, click anywhere on the diagram but on a component (in a empty zone actually), this will make the engine properties appear in the property panel.

The first field in the Engine Properties is the Current Clock.

High accuracy synchronization on the GPS clock

If your GPS has a Pulse-Per-Second digital output, RTMaps can be synchronized on the GPS clock with a high accuracy. The PPS signal transitions each second. The NMEA data then contains the full time corresponding to that second.

Here is how to enable this synchronization:

  1. Connect the PPS signal wire to the Ring pin of your serial port.
  2. Enable reading this pin in the RTMaps Serial Port component: select the component and set the "Use ring" property to falling edge or rising edge, depending on your PPS signal.
  3. Select the GPS UTC Clock Synchronizer and check the "Use PPS input" property. The component will create an input called "PPS signal".
  4. Connect your components as follows:Synchronization on GPS clock using PPS
  5. Right-click the GPS UTC Clock Synchronizer component and select Set as Main Clock.


How to convert an RTMaps database to another format ?

By setting the timelag of the player to infinite and the reader policy to NeverskippingReader, inputs can be processed as fast as possible.

  • Open the database in a "Player" component.
  • Set the "timelag" property of the Player to "infinite" so that there is no risk that the Player will discard some entries from the database (it will not skip lines in the .rec file) and may read the database with as much lateness as needed if the real-time speed cannot be reached.
  • Place any data processing components and a Recorder component on your diagram.
  • Organize the data flow between the Player and the processing components.
  • Edit the properties of the processing component inputs and set their type to "NeverskippingReader" instead of "FifoReader" so that no data can be dropped in an output fifo. (The neverskipping reader types will prevent upstream components to overwrite unprocessed data on their outputs).
  • Edit the Player output properties and set the "replay mode" to "Immediate" so that the Player will replay data as fast as possible on these tracks.
  • Connect the converted data outputs to the Recorder. Check the "Never skipping" and "Use timestamp" options so that no data can be dropped in an output fifo buffer, and the timeofissue informations are discarded (the data may be replayed with lateness or earliness depending on the computer load to perform the conversions).

  • As a result: the Player will try to read and output data as fast as possible. If the downstream processing components or the Recorder component cannot handle such framerate, they will block their upstream components up to the Player itself until they process a piece of data.

    Condition component

    The condition component allows you to do many powerful things in RTMaps. Let's point out a few of them.

    Detect a threshold

    Let's pretend we want to detect when a value goes over a certain threshold (10 for example). The condition would be : v{0} > 10 && v{-1} < 10

    It means that the current value must be above 10 and the previous value below 10. When you enter this expression in the condition property, RTMaps recognizes v as a variable. As a consequence, RTMaps immediately creates an input named "v" (see diagram above). Just connect your dataflow to this input and watch the condition output with a data viewer. Here is what you should observe :

    • 0 when the condition is false (default behaviour)
    • 1 when the condition is true (default behaviour)

    Indeed, 0 for false and 1 for true are default behaviours of the condition component. Of course, you can customize this behaviour : if the condition is TRUE, the output is the value contained by the Output when TRUE property, or 1 if nothing is filled in there. If the condition is false, the component uses the Output when FALSE, or 0 if the field is empty.

    Running a diagram in a loop

    The previous example used the output of the condition component. Now let's have a look to the the Parse when TRUE and Parse when FALSE fields, which are very powerful. Let's pretend we want to replay a diagram forever : when the replay is over, we shutdown the diagram and start again. This can be done automatically in RTMaps, thanks to the condition component !

    First, we have to find an ending condition for our component. Basically, we have two possibilities :

    • Since we know the replay ending time(for example 54 seconds), we could specify a time expiration : Engine.time > 54000000 (remember the time is in micro seconds in RTMaps).
    • Another possibility is to specify the replay percentage : Player_1.percentage == 100 . In that case the condition is true when the player has finished to output elements. (NB : the property is called Percentage with a capital P in the property panel. But this is an alias, and therefore not the real property name, which is percentage according to the Help).

    Now we must stop and run the diagram again when the condition is true. So we enter in the Parse when TRUE property:


    When the condition will be true, the diagram will be stopped and runned again, etc...

    Looping over a set of diagram

    Now what if we want to loop over a diagram sequence ? That means, the first diagram launches the second diagram, which in turns launches the third diagram, wich in turns launches the first diagram ! This could be very interesting during a stand presentation : RTMaps runs in stand alone mode so that you just have to present the results !

    To do that, you have to choose a ending condition (as in the previous example). For example : Engine.time > 10000000

    In the parse when TRUE property, we have to shutdown our diagram first, load the desired diagram, and then run it.

    So it gives:

    shutdown;loaddiagram <<C:\temp\diagram2.rtd>>; run

    You just have to tune each diagram so that it calls to the next and bob's your uncle !