Advanced Topic 7
The Last Position File
When launched from the command line, the MiniSim creates a file ending with the string “.lastpos.txt” when it exits as follows:
- The file is only created when the MiniSim is launched from the command line
- The restart will only work if the scenario is set up to stop the scenario when the vehicle either leaves the roadway or has a collision. Example Expression trigger content:
Expression Name: End Drive
Expression: ReadVar('MyTime') > 54000 this ends the scenario after 54,000 frames, or 15 minutes
Actions:
Action 1, Type=Set Variable, Variable=VisualDisplaytext, Value=End of Drive, Please Come To a Stop, Delay=5s
Action 2, Type=Terminate Simulation, Delay=0s
Action 3, Type=Set Variable, Variable=FinishedDrive, Value=1, Delay=0s Action 4, Type=Log Data, Variable=Stream 2, Value=1
- The drive complete indicator is defined in scenario.
- The restart file will be named the same as the daq filename that is passed into the MiniSim but with a “.lastpos.txt” so “my.daq” would produce a restart file of “my.daq.lastpos.txt”. An example of the contents of a .lastpos.txt file is as follows:
The 1st number indicates 1 if the scenario successfully finished The 2nd number is a number reserved by scenario control for the following:
- Default Nothing specified
- Collision with vehicle 2 Car drives off road
- Operator Abort – with restart
- Operator Abort – no restart
- The DAQ has encountered an error and stopped data collection. The 3rd number is the X position [feet]
The 4th number is the Y position [feet]
The 5th number is the Z position [feet]
The 6th number is the elapsed time in 1/60 sec counts from the scenario start and the participant exceeds a speed trigger (ie 10mph).
The customer’s launch application checks to see if the MiniSim has exited, then reads the contents of the lastpos file and initiates a restart through the command line for the codes: 0, 1, 2, 4.
The X,Y,Z position is the ‘last known good’ location of the driver on the roadway and when the customer’s launch application initiates a restart through the command line, the MiniSim ‘backs’ the driver up 1000’ from this last known good location.
The second line will indicate the name of the .daq file that was recorded. This is needed in case the same name on the daq file is passed, the daq will rename the new file as not to over-write an existing file. If the customer sends the same DAQ file name twice, the MiniSim re-names the DAQ file to prevent over-writing.
Advanced Topic 8
The Route Table
The Route Table for the NADS MiniSim provides the functionality for forwarding cell data over UDP “datagrams” to a specified location. The datagrams are sent at 60 Hz. The route table is specified by the routetable.txt file. This file must exist in the “MiniSimDir\bin” directory; if the file does not exist the MiniSim will operate normally, although no data will be forwarded.
The following is an example of a route table:
The route table is broken up into 3 sections, the “var”, “device”, and the “route”. The var section “declares” variables. Each section must begin with the section name, with no other text on the line, and must end with “end” on a line by itself. Variables are references to cells in the daq file, the devices are variables for output, and the route specifies the destination to send the data to. All lines that begin with “rem” are considered remarks and are discarded when the rout table is parsed.
Var
<name> <type> <size>
The var section declares a set of variables. Each line in the var section declares one variable. The first thing on the line is the variable name, this must be exactly the same as it appears in the .daq file or the .cec file, the next item (space or tab delimited) is the type:
'i': 32 bit integer
's': 16 bit short
'f': 32 bit floating point
'd': 64 bit floating point
'c': 8 bit character
The last element on the line is the size, this is the number of elements in the cell, in the above example SCC_Audio_Trigger is a single integer.
“FrameNum” is a special variable that does not have to be listed in the cec file, it will provide the current frame number. This is the same frame number that will appear in the daq file.
Device
<id> <type> <size> <e or n> “expression”
The device section is for declaring output variables. The first element on the device line, is the id. The id is used in the route section to reference the device. The next element is the type. This uses the same designation as the var section. The next element is the size, is the element count (currently only 1 is supported). Next specifies is the output is an expression (e) or just takes the value of a variable (n). Currently only expressions are supported so “e” must appear in this section. The last section is the expression. The expression must be in quotes. Each expression must have at least one operator. The so in the above expression the “SCC_Visual_Warning + 0 “, 0 is added to SCC_Visual_Warning as to not change its value. The value of the expression is always evaluated as a double, and then type casted to the type, so very large integers may get rounded off (double has 52 significant bits), in addition to any rounding that is done to convert the double to the output type. So in the above example:
11 c 1 e "SCC_Visual_Warning + 0"
We are taking the 16 bit SCC_Visual_Warning and outputting it as a 8 bit char
Route
<ip> <port> <packed?> <device1, device2,device3, …>
The route section specifies where to send data. The first element is the ip address, the second element is the port. The third element (0 or 1) specifies if the data is to be sent in a packed data format or using a NADS specific data protocol (not specified here). Next is a list of devices the devices are specified as above and will appear in the order as they are specified. The data will be sent as little endian. For the above example the address 191.168.0.101:1500, would be sent a datagram with a single 8 bit character data load at the rate of 60 Hz. When multiple devices are selected and packed is also specified no padding will appear between variables in the data load.
