$darkmode
#include <functional>#include <memory>#include <string>#include <vector>#include <cloe/component/ego_sensor.hpp>#include <cloe/component/lane_sensor.hpp>#include <cloe/component/latlong_actuator.hpp>#include <cloe/component/object_sensor.hpp>#include <cloe/component/object_sensor_functional.hpp>#include <cloe/handler.hpp>#include <cloe/models.hpp>#include <cloe/plugin.hpp>#include <cloe/registrar.hpp>#include <cloe/simulator.hpp>#include <cloe/sync.hpp>#include <cloe/utility/geometry.hpp>#include <cloe/vehicle.hpp>#include <minimator.hpp>Classes | |
| class | minimator::MinimatorLaneSensor |
| class | minimator::SimulatorSensorMockup |
| class | minimator::MinimatorObjectSensor |
| class | minimator::MinimatorEgoSensor |
| class | minimator::MinimatorVehicle |
| class | minimator::MinimatorSimulator |
Typedefs | |
| using | minimator::Vehicles = std::vector< std::shared_ptr< cloe::Vehicle > > |
This file defines the minimator example simulator plugin.
In principle, creating a simulator binding for Cloe is fairly simple. You must create a dynamic library that contains a plugin manifest that defines a factory that creates objects that fulfill the cloe::Simulator interface. (After introducing a class we will omit the cloe:: scope specification for brevity.)
The Simulator interface is little more than a cloe::Model that provides access to one or more cloe::Vehicle. As such it has a lot in common with all other models, such as cloe::Controller and cloe::Component.
We have then, the following situation:
Minimator is a Simulator, which is a Model. Minimator provides MinimatorVehicle, which is a Vehicle. MinimatorFactory is exported with EXPORT_CLOE_PLUGIN. Fable library for this purpose. This is included in the Cloe runtime and is available in the cloe namespace as well as the original fable namespace.