![]() ![]() Some experiments include playing videos (e.g. Most have questionnaires of various forms, after some or all scenarios. However, for us, that’s not really how experiments actually go. Your study has X scenarios, you run them in different orders, and that’s it. Scenarios are often considered as the “unit” of the experiment. Those examples illustrate some ways in which we’re expanding the usual definition of what a scenario is, allowing researchers to study more subjects at greater depth, and requiring agile development of the platform. The modular units were tailored-made for this project, but the idea can be applied to any driving simulation experiment. making a “thank you” gesture), or even buildings and itineraries (to ensure that the participant wouldn’t have an habituation effect from driving around the same city). With our modular elements, we were able to easily change the CAV’s braking pattern, the pedestrian’s behavior (e.g. In our latest experiment, which studies CAV-pedestrian interactions, we made basic modular scenario elements, allowing combination of those to create a very wide range of scenario variants (more on that later!). For this experiment, we had to implement various innovative HMIs, sometimes requiring complex interactions, and develop scenarios to make it so that each one could be run with each HMI. To do that, participants experienced multiple autonomous lane-changes, and based on their feedback for each, custom scenarios were procedurally generated at runtime to have more in-depth insights for each participant.Īnother example is a complex study on take-over from automated driving in critical situations, where we designed and tested multiple HMIs to help the driver take over. ![]() One example is a study by Jonathan Deniel, where he looked at automated driving effects on driver’s decision-making. We’re finding new and innovative ways to study drivers’ behavior. As an engineer, I’m always looking for new ways to allow researchers to expand simulator experiments beyond the current state of the art. One reason why OpenSCENARIO doesn’t really fit our needs is because we tend to push the definition of what a scenario is. So I’m not a big fan of OpenSCENARIO, but I’m still following their work, hoping that the future will bring more features in alignment with our “simple” driving simulation requirements. Last I checked, they even had their own Domain-specific language, which might be a good idea in theory, but doesn’t really align with our “easy and intuitive” philosophy. ![]() The 2.0 Concept release, on the other hand, is too broad in coverage, ranging from automated testing for ADAS development, to driver model, and more. I haven’t spent much time studying it, but the 1.x, and its XML format, was too restrictive in its scenario definition, and I’ve found quite a few examples of scenarios we had previously implemented that wouldn’t have been possible with this standard. That alone could be enough to deter us from using OpenSCENARIO, but I’m not really pleased with the standard itself. The current “two versions” state of the standard definitely doesn’t help anyone looking to fill that space. I know that VectorZero was working on a Scenario Editor before it was bought by Mathworks, but no news on that. Even though you can find some players (like esmini), I don’t have knowledge of any editor out there. It doesn’t help that, just as the beginning as OpenDRIVE, tooling is not quite there yet. Even if the end goal is for the two releases to converge, right now the standard is in a weird place. Its 1.x release is still being worked on, all the while a much more ambitious 2.0 Concept is nearing release. In the same way as OpenDRIVE, OpenSCENARIO is currently between two versions. The primary use-case of OpenSCENARIO is to describe complex, synchronized maneuvers that involve multiple entities like vehicles, pedestrians and other traffic participants. ![]() OpenSCENARIOĪfter OpenDRIVE was initially released, the PEGASUS consortium started to work on an even more ambitious standard: OpenSCENARIO.ĪSAM OpenSCENARIO defines a file format for the description of the dynamic content of driving and traffic simulators. But we also want this process to be as easy and intuitive as possible, so that non-experts can start working on their scenario as early as possible in the experiment design phase, allowing for quick and iterative development. We want to offer as much control as possible to researchers, allowing them to build any experiment they can imagine. An important and critical stage in driving simulator experiments is scenario authoring. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |