Purpose
@FireBoyAJ24 worked on test plans. @jb3982 further improved them to let us run the test plans sequentially. Now, we want to go one step further by making the test plans dynamic.
The idea is to define mock inputs in a detailed YAML file using timestamped events. Each event describes when a mock input should change relative to the start of the test plan. For example, mock_wind_sensor could contain a list of wind updates, where each update includes the wind direction in degrees, wind speed in km/h, and a relative timestamp for when that update should be applied.
The timestamps should be strictly monotonic, meaning each new event must occur after the previous one. This makes the test plan deterministic and easier to reason about.
Example format:
events:
mock_wind_sensor:
- timestamp: 0.0
direction_deg: 90
speed_kmph: 12
- timestamp: 5.0
direction_deg: 110
speed_kmph: 18
- timestamp: 10.0
direction_deg: 135
speed_kmph: 20A similar structure can be used for other mock inputs such as mock_gps, mock_global_path, mock_ais, and other mocked sensors or planning inputs. Each mock input would define its own list of timestamped values, allowing the test plan to simulate changing world conditions over time.
You might be wondering, "why do this?". Glad you asked. We will use AI to generate this file to mimic ocean data or we can even take the OWT data pass it to AI and convert it to this file for ease of use. But we will REQUIRE strong checks on plausibility for example angles being within the right range or the wind speed not going to let's say 5000kmph,
Purpose
@FireBoyAJ24 worked on test plans. @jb3982 further improved them to let us run the test plans sequentially. Now, we want to go one step further by making the test plans dynamic.
The idea is to define mock inputs in a detailed YAML file using timestamped
events. Each event describes when a mock input should change relative to the start of the test plan. For example,mock_wind_sensorcould contain a list of wind updates, where each update includes the wind direction in degrees, wind speed in km/h, and a relative timestamp for when that update should be applied.The timestamps should be strictly monotonic, meaning each new event must occur after the previous one. This makes the test plan deterministic and easier to reason about.
Example format:
A similar structure can be used for other mock inputs such as
mock_gps,mock_global_path,mock_ais, and other mocked sensors or planning inputs. Each mock input would define its own list of timestamped values, allowing the test plan to simulate changing world conditions over time.You might be wondering, "why do this?". Glad you asked. We will use AI to generate this file to mimic ocean data or we can even take the OWT data pass it to AI and convert it to this file for ease of use. But we will REQUIRE strong checks on plausibility for example angles being within the right range or the wind speed not going to let's say 5000kmph,