Advanced Topic 7 - Revision history

Andrew Veit at 18:51, 15 April 2022

2022-04-15T18:51:53Z

Steve Cable: /* The Route Table */

2019-01-10T18:25:41Z

‎The Route Table

Anna Dizack at 19:55, 24 February 2017

2017-02-24T19:55:24Z

Ciera Headley at 21:53, 18 October 2016

2016-10-18T21:53:41Z

Ciera Headley at 21:50, 18 October 2016

2016-10-18T21:50:41Z

Ciera Headley at 21:49, 18 October 2016

2016-10-18T21:49:28Z

Ciera Headley at 21:48, 18 October 2016

2016-10-18T21:48:58Z

Ciera Headley at 21:48, 18 October 2016

2016-10-18T21:48:28Z

Ciera Headley: /* Advanced Topic 8 */

2016-10-18T21:46:30Z

‎Advanced Topic 8

Ciera Headley: /* The Last Position File */

2016-10-18T21:37:42Z

‎The Last Position File

@@ Line 3: / Line 3: @@
 [[Advanced_Topic_5|◄PREVIOUS]]       [[Advanced_Topic_10|NEXT►]]
 ==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:
+MiniSim creates a file ending with the string “.lastpos.txt” in the DAQ folder when the simulation ends. This file is used in certain specific applications where an external application launches miniSim from the command line (see Advanced Topic 8), and monitors its status by looking for a specific process running (i.e. SimopServer.exe) and reading the lastpos.txt file. When the simulation exists, the external system then decides, based on the content of the lastpos file, weather the drive is 'complete' of if a 'restart is needed'. The external system can also log the status of each drive, DAQ file names, number of restarts, etc.
-#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.
-#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
+Example trigger Actions:
 Actions:
@@ Line 24: / Line 25: @@
 [[File:3040.png|550px|thumb|center]]
-The 1st number indicates 1 if the scenario successfully finished
+The 1st number indicates 1 if the scenario successfully finished:
-The 2nd number is a number reserved by scenario control for the following:
+= not complete
-# Default Nothing specified
+= successfully finished
-# Collision with vehicle 2 Car drives off road
-# Operator Abort – with restart
+The 2nd number is a number signifies the following when the simulation terminates:
-# Operator Abort – no restart
+= Default, nothing specified
-#The DAQ has encountered an error and stopped data collection. The 3rd number is the X position [feet]
+= Collision with vehicle
-The 4th number is the Y position [feet]
+Note: The Operator Abort (4, 5) are set when the miniSim is launched from the command line with the -AutoDrive option. If the operator clicks on the 'Stop' button, a GUI pops up with two options: 'Restart and 'Stop'. The collision and off road crash codes are set by trigger actions writing to log stream 2. The DAQ Collection failure is code is generated by the DAQMonitor.exe subsystem.
-The 5th number is the Z position [feet]
+The 3rd number is the external driver X 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 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.
 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.

@@ Line 53: / Line 53: @@
 [[File: rem.png|500px|thumb|center]]
-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.
+For more information, see the [[Route Table|Route Table]] page.
-−
-'''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:
-−
-	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.
-−
-[[Advanced_Topic_5|◄PREVIOUS]]       [[Advanced_Topic_10|NEXT►]]

← Older revision		Revision as of 19:55, 24 February 2017
Line 1:		Line 1:
		+	[[Table of contents\|Table of Contents]]
		+
	[[Advanced_Topic_5\|◄PREVIOUS]] [[Advanced_Topic_10\|NEXT►]]		[[Advanced_Topic_5\|◄PREVIOUS]] [[Advanced_Topic_10\|NEXT►]]
	==The Last Position File==		==The Last Position File==

@@ Line 1: / Line 1: @@
-[[Advanced_Topic_5|◄PREVIOUS]]       [[Advanced_Topic_9|NEXT►]]
+[[Advanced_Topic_5|◄PREVIOUS]]       [[Advanced_Topic_10|NEXT►]]
 ==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:
@@ Line 89: / Line 89: @@
 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.
-[[Advanced_Topic_5|◄PREVIOUS]]       [[Advanced_Topic_9|NEXT►]]
+[[Advanced_Topic_5|◄PREVIOUS]]       [[Advanced_Topic_10|NEXT►]]

@@ Line 1: / Line 1: @@
-[[Advanced_Topic_5|◄PREVIOUS]]       [[Advanced_Topic_9|NEXT]]
+[[Advanced_Topic_5|◄PREVIOUS]]       [[Advanced_Topic_9|NEXT►]]
 ==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:
@@ Line 89: / Line 89: @@
 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.
-[[Advanced_Topic_5|◄PREVIOUS]]       [[Advanced_Topic_9|NEXT]]
+[[Advanced_Topic_5|◄PREVIOUS]]       [[Advanced_Topic_9|NEXT►]]

@@ Line 1: / Line 1: @@
 ==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:
@@ Line 41: / Line 42: @@
 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==
@@ Line 86: / Line 88: @@
 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.

← Older revision		Revision as of 21:46, 18 October 2016
Line 48:		Line 48:

	[[File: rem.png\|500px\|thumb\|center]]		[[File: rem.png\|500px\|thumb\|center]]
		+
		+	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.

← Older revision		Revision as of 21:37, 18 October 2016
Line 20:		Line 20:

	[[File:3040.png\|550px\|thumb\|center]]		[[File:3040.png\|550px\|thumb\|center]]
		+
		+	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:
		+
		+	[[File: rem.png\|500px\|thumb\|center]]