Using the Foretify Command-Line Interface
Foretify run execution flow
In order to understand the concrete situations that take place during test execution and also to debug eventual failures or gray-area behavior, it is useful to know the stages of the test execution and how different components interact with each other.
The first stage in the test flow is to load the OSC2 sources. These are loaded one by one, according to import order in the OSC2 Reference. The next step is to load and interpret the map that the scenario will use.
At this point Foretify is ready to plan the list of actions. This phase expands the behavior described in the scenario into finer granularity movement scenarios. It also chains various phases in the scenario.
If the planning phase succeeds, the test moves to simulation. In this phase the Foretify engine starts interacting with the simulator:
- Advancing the simulation
- Retrieving the actors’ dynamic information (position, speed, acceleration)
- Adjusting the plan, if necessary, in order to achieve the plan’s goals.
You must keep in mind that in any AV simulation there is a grain of unpredictability: SUT can take unpredictable decisions to handle situations when forced by the traffic context. This means that the plan does not always match reality. Foretify alleviates the side effects of unexpected SUT behavior by adjusting the plan at the end of each simulation step.
Executing a single run interactively
To execute a single interactive run with the Foretify GUI:
-
Load the test file into the Foretify GUI:
Shell command: invoke Foretify with GUI$ foretify --load <test-file> --gui -
In the Terminal Pane, type the run command.
-
To exit Foretify, enter the quit command.
To execute a single interactive run using the Foretify Command-Line Interface:
-
Load the test file into Foretify:
Shell command: invoke Foretify with CLI$ foretify --load <test-file> -
At the foretify> prompt, type the run command.
Executing a single run in batch
To execute a single batch run, invoke Foretify with the --load, --run and --batch options.
$ foretify --load <test-file> --run --batch
Viewing run data
For each run, Foretify creates a new folder under the <work_dir>/runs folder. The timestamp is used as the name of the folder.
The folder contains all the information required in order to recover a previous run, either for debugging purposes or in order to re-execute the run.
Resources included in the <work_dir>/runs/<timestamp>/ folder are:
- source/ is a directory containing all the OSC2 files loaded into Foretify during the run, including user source files.
- xviz_data/ is a directory containing zip files with the Visualizer data from the run.
- debug_data.pb.gz and run_data.pb.gz are internal Foretellix files that are used by Foretify and Foretify Manager for coverage calculation and single-run debugging.
- public_data.pb.gz contains the raw data collected during the Foretify run.
- run_info.json contains the metadata for the run.
- run.log is the log file for the run.
You can use the public_data.pb.gz file to quickly access the information in its raw format before it is processed by Foretify Manager. There are two methods to access the information in the public_data.pb.gz files:
-
Use a programming language to access the data.
The Foretify release includes a file $FTX/interfaces/run_results/public.proto that defines the schema of the run results.
Using the public.proto file, you can generate the required header files using the Protobuf compiler, For information on how to do this, see Protocol Buffers Tutorials.
-
Use Foretify's run_results_parser to convert the binary results into a text-based JSON file.
Shell command: convert the public data file$ $FTX/bin/run_results_parser/run_results_parser <path to run folder>After executing the script, the run folder contains a new file called public_data.json. You can be read the file with any text editor application.
Re-executing a run
You can recover a run by selecting it in the History tab of the Foretify GUI, or by loading it during invocation using the --load_run option:
$ foretify --load_run <run_folder>
Note
When re-executing a run, Foretify does not read from the run's source directory, but instead from the Protobuf file (<rundir>/debug_data.pb.gz). This means that changing the files in the source directory for the purposes of a rerun is not supported. See Viewing run data for details about run directories.
When you load a run that was executed with a Foretify version different than the current one, you receive a warning specifying that re-executing the run might yield different results.
Recording a run for later replay at Foretellix
You can record a Foretify test execution in your environment, and send the run results to Foretellix for reproduction. This shipped data enables Foretify to reproduce the entire run on the Foretify side without depending on other components, such as the SSP/Simulator and DSP/SUT.
To record a test run, set the option debug_record at Foretify startup.
$ foretify [other options] --debug_record
runtime:
debug_record: true
All test run folders created when Foretify is executed in this mode contain an additional recording file that allows reproduction of the run by Foretellix. Please ship the generated run folder (created under <work_dir>/runs/) to Foretellix.
At Foretellix, invoke Foretify wtih the debug_replay option to re-run the recorded test. You can load additional OSC2 files to help with the debugging if you want.
$ foretify --debug_replay <path to received folder>
You can view the re-run results in log, Visualizer, and any other debug method such as trace.
Recording simulator videos
If you use the CarMaker or Carla simulator, you can record a video of your Foretify test execution. To record a video of a Foretify run with CarMaker or Carla, configure your test to use the simulator, then use the --record_video option on the command line:
foretify --load <osc_file> --record_video
If the Foretify run folder is accessible to the Simulator Support Package (SSP), the mp4 is written to the run folder. For CarMaker, if this folder can't be accessed by the SSP, for example, if you're running on a separate machine, then the mp4 is written to the SimOutput folder of the CarMaker project. The output filename has the Foretify run ID as its prefix.
See also the record_video documentation.
CarMaker recording prerequisites and limitations
-
CarMaker must be running in GUI mode or CarMaker for Simulink (CM4SL).
-
The CarMaker TCP ScriptControl port must be opened and set to port 64791. For regular CarMaker, set this in the
.CarMaker.tclstartup script. For CM4SL, set this with the MATLAB commandCMData.CmdPort = 64791;. -
To export video, IPGMovie must be running and connected at the end of the test. IPGMovie should be automatically started by the
.CarMaker.tclstartup script. -
If the SSP is run remotely and the video is not written to the run folder, Foretify will not be able transcode the video to h264.
See the CarMaker Programmer's Guide for information about using IPGMovie.