paulbourelly999
commented
9 months ago After talking more about this I think this fix should not be necessary. Negative Vf should only be an issue if you generate a position trajectory that has a non 0 initial velocity and a zero first delta d. The fix should be up stream components should generate a trajectory that has at least one step of delta d to account for the distance covered during acceleration. This will fix the negative signal. We should also log some kind of error for negative VIs and then I think it is OK to call max.
sonarcloud[bot]
PR Details
Description
This PR handles a case where the measured speed value when stopping can be negative value, which we can be set to 0 safely.
However, if it is a large negative value, the only way it can happen is if the initial trajectory generation is wrong. So this function throws an exception to indicate the user. This forces the developer to generate physics-conforming trajectory. Previously this case was handled by forcing it 0, but it wasn't applying at the correct place. Now it still applies 0 to negative values as a safety feature.
This throw behavior caught an error in the stop_and_wait_plugin at this time, which is partially handled in this PR: https://github.com/usdot-fhwa-stol/carma-platform/pull/2272
Related GitHub Issue
https://github.com/usdot-fhwa-stol/carma-utils/issues/211
Related Jira Key
https://usdot-carma.atlassian.net/browse/CDAR-717 CDAR-717
Motivation and Context
How Has This Been Tested?
cdasim pc 1 integration tested with vru use case 1
Types of changes
Checklist: