A leading idea was to employ the same environment for the software development than for the runtime, with a minimum adaptation time for porting it from one to the other. The subsystems were first tested in simulation, within a development environment named ATMEnvs (Curti et al., 2005) such that the software could be directly ported to the vehicle when these simulation tests were successful. Thus, the simulation environment was communicated with the vehicle software through the serial port, using an adaptor between the NMEA protocol and the messages within a proprietary communication protocol among modules. In this way, once the software is operative, the simulator is easily and straightforward replaced by the real hardware prototype. The simulation environment included cinematic and dynamic linear models of the vehicle. The static information among the different modules was shared through bottom specification files (*.bsf) and objective under inspection specification files (*.psf). The information associated with the dynamic variables among the modules travel in the messages mentioned before, the same that is employed when the robot is operating in its real environment.
Referring to figure 2 in Section 3.2, the DMP and OAS constitute a system in cascade connection; consequently, if the OAS did not detect any object through the FLS, its output will be simply the desired trajectory from the DMP. On the contrary, if an obstacle is detected, the OAS changes the necessary waypoints in the trajectory provided by the DMP.
Was this article helpful?