TechnicalArticles
2008-01-06, 16:32
An Integrated Environment for the Modeling, Simulation, and Rapid Design of Control Algorithms for Mobile Robots
by Ivan Masar ([email protected]) and Rolf Gabler
University of Hagen, Germany (http://www.fernuni-hagen.de/)
Researchers in the Process Control and Control Engineering Department at the University of Hagen are working on a distributed multirobot system with several cooperating ground and aerial mobile robots. Such a heterogeneous multirobot system with various kinematic and aerostatic subsystems can perform complex tasks in extremely demanding environments. To conduct our research, the team developed the mobile experimental robot F.A.A.K. (translated from the Slovak “Fully Autonomous Advanced Vehicle”) and an airborne blimp equipped with sensors and actuators (Figure 1). The two robots rely on digital signal processors (DSP) to calculate the algorithms for ground and air travel maneuvers, evaluate the sensor input, and control the robots' actuators. A high-level DSP-based image processing system provides visual navigation capabilities for both robots. Communication and data transfer between individual robots enables engineers to coordinate and prioritize task sequences and optimize assignments, thus increasing the autonomy of the overall system (Figure 2).
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_faak.jpg
Figure 1. The F.A.A.K. mobile robot and the blimp.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_cooperation.jpg
Figure 2. Cooperation in a multirobot system.
The process of developing, implementing, and fine-tuning control strategies for this type of complex multirobot system is extremely time-consuming. Our team used the MATLAB (http://www.mathworks.com/products/matlab/) and Simulink (http://www.mathworks.com/products/simulink/) product families to design an integrated environment for modeling, simulating, and rapidly prototyping algorithms, with components that:
Simulate the dynamic models of the robots and their individual subsystems, such as the actuators and sensors
Model the robots' environments
Perform a complex simulation of the overall multirobot system
Automatically generate code for DSP-based robot control
Communicate with the robots and control them remotely This article describes these components and their application, along with the mobile ground-level system (the F.A.A.K).
The Mobile Robot (F.A.A.K.)
The F.A.A.K. mobile robot is an experimentation platform with an unconventional drive concept. The robot is equipped with four steered wheels, two of which are driven. This kinematic configuration is very stable at high speeds and can move in any direction (Figure 3).
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_movement_w.gif (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_movement_wl.gif)
Figure 3. Movement types achieved by the F.A.A.K. robot. Click on image to see enlarged view.
We selected geared DC motors driven by Pulse-Width Modulation (PWM) signals to steer and drive the vehicle, and used 24-bit incremental encoders to measure the angle of rotation of the wheels.
The robot's sensor system consists of a Charge-Coupled Device (CCD) line sensor on the robot's underside that detects floor characteristics (such as travel guidelines) together with infrared sensors for detecting obstacles.
We chose a Texas Instruments TMS320LF2407 fixed-point DSP to control the robot. This DSP is designed for use in control applications and consists of the DSP core processor together with extensive I/O periphery, integrated directly on the chip and featuring timer/counter modules, a watchdog module, a 16-channel AD converter, a CAN module, modules for asynchronous (SCI) and synchronous (SPI) serial communications, a digital input/output, and an additional JTAG port for processor emulation. It performs the following tasks:
Reads and evaluates sensor signals
Calculates and generates control signals for the drive and control motors
Navigates the robot through the environment using onboard odometry
Communicates with an external monitoring system
Implements demanding, "intelligent" handling strategies (such as avoiding local collisions, automatically learning system parameters, generating maps, planning global routes, etc.) Using the DSP's asynchronous serial interface, the robot communicates with the stationary monitoring computer, receiving travel instructions and returning information. A Radiometrix radio module (BiM2-433) installed on the robot enables wireless communication with an external control computer or with the other robots.
The F.A.A.K. robot is also equipped with controllable digital cameras and an image processing system for visual servoing. The image data is processed in a higher-level TI C5000-series DSP and the robot employs dual-port RAM for communicating between the two processors. Figure 4 illustrates the connection between the individual robot subsystems and the DSP processors together with the communications channels.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_multidsp_w.jpg (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_multidsp_wl.jpg)
Figure 4. Communication in the multi-DSP environment, and the connection of robot subsystems. Click on image to see enlarged view.
Simulating the Robot
The first step in designing a control algorithm is creating a model of the controlled system and then validating it with simulations. To do this, we designed a Simulink library containing the robot and sensor models. Using Simulink Fixed Point (http://www.mathworks.com/products/simfixed/) was particularly efficient for developing the control algorithms. As the microcomputer used in the mobile robot is a fixed-point DSP, we used it to simulate the digital controllers, filters, look-up tables and other algorithms in precisely the same format in which they will be implemented in the actual robot. This enabled us to identify digital weak points during the simulation stage, thus avoiding the time-consuming task of identifying them during robot travel. It also meant we could immediately use the designed and tested fixed-point algorithms for code generation. We generated complete steering algorithms, which were required as modules for complex robot motion control (Figure 5).
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_3dvrml_w.jpg (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_3dvrml_wl.jpg)
Figure 5. Simulation of the control of the robot's steering angle and a visualization of the wheel movements based on its 3-D VRML virtual world (using the Virtual Reality Toolbox). Click on image to see enlarged view.
However, simple simulations of the robot model are not sufficient to simulate the autonomous behavior of a mobile robot (or a multirobot system), since such simulations do not contain the robot's interactions with its environment or with other robots. For this reason, we designed the MapGen tool, which enabled us to design artificial worlds so that we could simulate the robots in various environments characterized by different obstacles. The MapGen GUI let us create an environment with a variety of objects and then store the environment as a structured map in a MAT file. We could then use the generated map in a simulation, together with the robot and the sensor models, to depict the external robot sensors’ output signals, and thus fully implement the complex sensor strategies in the simulation. (You can also use the map to automatically create a 3-D VRML model and then process a “virtual” sensor image obtained from the 3-D model.) Figure 6 illustrates how to use the MapGen tool.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_mapgen_w.jpg (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_mapgen_wl.jpg)
Figure 6. Using MapGen. Click on image to see enlarged view.
Automatic Code Generation for the DSP
The next step in designing control algorithms is to implement and test them in the DSP using hardware-in-the-loop (HIL) simulations. In the past, it was necessary to program the real-time software for the robot by hand-coding the algorithms in C using an editor and then compiling the code.
Instead, we used the Embedded Target for TI C2000 DSP (http://www.mathworks.com/products/tic2000/) to generate code automatically and deploy it onto the robot's control processor. In conjunction with Link for Code Composer Studio (http://www.mathworks.com/products/ccslink/) this product connects MATLAB and Simulink to the TI Code Composer Studio software development environment, which creates the real-time application. Using Real-Time Workshop (http://www.mathworks.com/products/rtw/) we generated C-code from the Simulink model and compiled and linked it using the TI compiler and linker. We loaded the code immediately into the robot's DSP, greatly reducing the time needed to fine-tune and test the algorithm.
We also developed a system to monitor and display the data, so we could compare the real and simulated data and check the functionality of the implemented controller. Figure 7 illustrates the complete rapid prototyping process for the robot.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_tic2000_w.jpg (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_tic2000_wl.jpg)
Figure 7. Rapid prototyping with the TI C2000 DSP. Click on image to see enlarged view.
To add to the DSP peripheral module support provided by the Embedded Target for the TI C2000 DSP (A/D converter, PWM generators, digital I/Os, and counters), we used Simulink S-functions to create additional sensor and communication interfaces and implement them as separate blocks. These functions included:
Digital inputs – This function reads the push-button values for robot operation.
Digital outputs
A/D conversion – Implementing extended A/D conversion made it possible to specify the prescaler, the conversion mode (either one conversion or the mean of multiple successive conversions) and the resulting shift.
Initializing and reading the external counters for the incremental encoders – The DSP has to control six DC motors simultaneously (four for steering and two drive motors). Its internal counters are not sufficient for the incremental encoding of all the motors. For these reasons, the output signals of the incremental encoders are evaluated using six type LS7166 counter modules and then read in by the DSP over a digital I/O data bus.
Operating and evaluating the data from the line camera – The line camera is controlled through digital outputs and the data is transferred through the synchronous serial interface (SPI). Evaluation of the received data, subsequently performed in the DSP, is also implemented through this block.
Serial communication – This function permits hard-wired or wireless communication between the robot and a monitoring PC or other robots. Figure 8 shows the custom blocks for the robot subsystems.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_supportblks_w.jpg (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_supportblks_wl.jpg)
Figure 8. Real-time support blocks for the F.A.A.K. robot. Click on image to see enlarged view.
We also reprogrammed the code generation for the processor's digital I/O to permit checking the assignment of the functions to individual DSP pins and settings of the corresponding DSP registers. There is a danger that multiple S-functions may attempt to use an I/O channel for different purposes, or that one S-function will overwrite the settings made by another S-function when writing to a register. To prevent this, the associated DSP registers are initialized in a central initPins function. During code generation, Real-Time Workshop TLC scripts generate this function in accordance with the S-functions present in the Simulink model. Each use of a DSP I/O pin is stored in a global structure. Once the code is generated for individual blocks, the system determines whether any conflicts have been detected. Using this method, it is easy to locate and correct conflicts, even in complex models. Figure 9 shows an example of the generated initPins function.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_initpins_w.gif (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_initpins_wl.gif)
Figure 9. Generated initPins function. Click on image to see enlarged view.
Communicating with the Robot
After the generated program is transferred to the DSP, the robot can execute the tested algorithm. To evaluate the data from the robot, we designed a communication mode between MATLAB and the robot that uses the serial interface via a serial cable or using radio modules.
There are two types of data transfer mode:
Online data transfer – The data transfer generally used to represent important robot parameters from each time cycle for monitoring purposes at the operating PC.
Offline data transfer – This transfer mode makes it possible to record data over a limited period for subsequent offline evaluation, as in the analysis of a specific travel maneuver. The number of signals to be recorded can be configured in the model. You can start recording with a trigger signal (recording trigger) and the data is initially buffered in the robot's onboard memory. Recording stops at the end of the buffer. A second trigger signal (transmit trigger) is then issued to start data transfer. The number of parameters and the buffer length are limited by the available DSP memory. The state diagram in Figure 10 illustrates the data recording sequence. http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_state.gif
Figure 10. State diagram for offline data recording. Click on image to see enlarged view.
The data is read into MATLAB through the serial port and can either be plotted in the FAAKComm tool (a GUI developed in MATLAB by the team) or used to animate the robot's 3-D VRML model. Figure 11 shows the FAAKComm tool displaying real data obtained from the real-time robot steering mechanism control. With the FAAKComm’s setting, it is possible to configure the serial communication parameters (port, baud rate, type, and number of transferred signals) and also the data display mode and automatic file storage of the received data.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_faakcomm_w.gif (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_faakcomm_wl.gif)
Figure 11. FAAKComm. Click on image to see enlarged view.
Results and Future Extensions
The integrated environment we describe here for developing mobile robotic control algorithms represents a complex platform consisting of multiple components. Engineers can use these tools for individual design stages such as model construction, simulation, code generation, HIL, and data analysis to accelerate the entire development process. The MATLAB and Simulink product families enable rapid development compared to designing “from scratch.” This results in a simple, highly flexible path for future developments and adding new functions.
We plan to extend our simulation environment with a working blimp model in the near future. This should enable us to derive and implement innovative strategies for cooperation between the ground-level and aerial systems. Further planned developments include simulating the embedded inter-DSP communication with the image processing system, along with automatic code generation for the TI C5000™ DSP.
更多... (http://www.mathworks.com/company/newsletters/digest/2005/sept/mobile_robots.html)
by Ivan Masar ([email protected]) and Rolf Gabler
University of Hagen, Germany (http://www.fernuni-hagen.de/)
Researchers in the Process Control and Control Engineering Department at the University of Hagen are working on a distributed multirobot system with several cooperating ground and aerial mobile robots. Such a heterogeneous multirobot system with various kinematic and aerostatic subsystems can perform complex tasks in extremely demanding environments. To conduct our research, the team developed the mobile experimental robot F.A.A.K. (translated from the Slovak “Fully Autonomous Advanced Vehicle”) and an airborne blimp equipped with sensors and actuators (Figure 1). The two robots rely on digital signal processors (DSP) to calculate the algorithms for ground and air travel maneuvers, evaluate the sensor input, and control the robots' actuators. A high-level DSP-based image processing system provides visual navigation capabilities for both robots. Communication and data transfer between individual robots enables engineers to coordinate and prioritize task sequences and optimize assignments, thus increasing the autonomy of the overall system (Figure 2).
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_faak.jpg
Figure 1. The F.A.A.K. mobile robot and the blimp.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_cooperation.jpg
Figure 2. Cooperation in a multirobot system.
The process of developing, implementing, and fine-tuning control strategies for this type of complex multirobot system is extremely time-consuming. Our team used the MATLAB (http://www.mathworks.com/products/matlab/) and Simulink (http://www.mathworks.com/products/simulink/) product families to design an integrated environment for modeling, simulating, and rapidly prototyping algorithms, with components that:
Simulate the dynamic models of the robots and their individual subsystems, such as the actuators and sensors
Model the robots' environments
Perform a complex simulation of the overall multirobot system
Automatically generate code for DSP-based robot control
Communicate with the robots and control them remotely This article describes these components and their application, along with the mobile ground-level system (the F.A.A.K).
The Mobile Robot (F.A.A.K.)
The F.A.A.K. mobile robot is an experimentation platform with an unconventional drive concept. The robot is equipped with four steered wheels, two of which are driven. This kinematic configuration is very stable at high speeds and can move in any direction (Figure 3).
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_movement_w.gif (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_movement_wl.gif)
Figure 3. Movement types achieved by the F.A.A.K. robot. Click on image to see enlarged view.
We selected geared DC motors driven by Pulse-Width Modulation (PWM) signals to steer and drive the vehicle, and used 24-bit incremental encoders to measure the angle of rotation of the wheels.
The robot's sensor system consists of a Charge-Coupled Device (CCD) line sensor on the robot's underside that detects floor characteristics (such as travel guidelines) together with infrared sensors for detecting obstacles.
We chose a Texas Instruments TMS320LF2407 fixed-point DSP to control the robot. This DSP is designed for use in control applications and consists of the DSP core processor together with extensive I/O periphery, integrated directly on the chip and featuring timer/counter modules, a watchdog module, a 16-channel AD converter, a CAN module, modules for asynchronous (SCI) and synchronous (SPI) serial communications, a digital input/output, and an additional JTAG port for processor emulation. It performs the following tasks:
Reads and evaluates sensor signals
Calculates and generates control signals for the drive and control motors
Navigates the robot through the environment using onboard odometry
Communicates with an external monitoring system
Implements demanding, "intelligent" handling strategies (such as avoiding local collisions, automatically learning system parameters, generating maps, planning global routes, etc.) Using the DSP's asynchronous serial interface, the robot communicates with the stationary monitoring computer, receiving travel instructions and returning information. A Radiometrix radio module (BiM2-433) installed on the robot enables wireless communication with an external control computer or with the other robots.
The F.A.A.K. robot is also equipped with controllable digital cameras and an image processing system for visual servoing. The image data is processed in a higher-level TI C5000-series DSP and the robot employs dual-port RAM for communicating between the two processors. Figure 4 illustrates the connection between the individual robot subsystems and the DSP processors together with the communications channels.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_multidsp_w.jpg (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_multidsp_wl.jpg)
Figure 4. Communication in the multi-DSP environment, and the connection of robot subsystems. Click on image to see enlarged view.
Simulating the Robot
The first step in designing a control algorithm is creating a model of the controlled system and then validating it with simulations. To do this, we designed a Simulink library containing the robot and sensor models. Using Simulink Fixed Point (http://www.mathworks.com/products/simfixed/) was particularly efficient for developing the control algorithms. As the microcomputer used in the mobile robot is a fixed-point DSP, we used it to simulate the digital controllers, filters, look-up tables and other algorithms in precisely the same format in which they will be implemented in the actual robot. This enabled us to identify digital weak points during the simulation stage, thus avoiding the time-consuming task of identifying them during robot travel. It also meant we could immediately use the designed and tested fixed-point algorithms for code generation. We generated complete steering algorithms, which were required as modules for complex robot motion control (Figure 5).
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_3dvrml_w.jpg (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_3dvrml_wl.jpg)
Figure 5. Simulation of the control of the robot's steering angle and a visualization of the wheel movements based on its 3-D VRML virtual world (using the Virtual Reality Toolbox). Click on image to see enlarged view.
However, simple simulations of the robot model are not sufficient to simulate the autonomous behavior of a mobile robot (or a multirobot system), since such simulations do not contain the robot's interactions with its environment or with other robots. For this reason, we designed the MapGen tool, which enabled us to design artificial worlds so that we could simulate the robots in various environments characterized by different obstacles. The MapGen GUI let us create an environment with a variety of objects and then store the environment as a structured map in a MAT file. We could then use the generated map in a simulation, together with the robot and the sensor models, to depict the external robot sensors’ output signals, and thus fully implement the complex sensor strategies in the simulation. (You can also use the map to automatically create a 3-D VRML model and then process a “virtual” sensor image obtained from the 3-D model.) Figure 6 illustrates how to use the MapGen tool.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_mapgen_w.jpg (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_mapgen_wl.jpg)
Figure 6. Using MapGen. Click on image to see enlarged view.
Automatic Code Generation for the DSP
The next step in designing control algorithms is to implement and test them in the DSP using hardware-in-the-loop (HIL) simulations. In the past, it was necessary to program the real-time software for the robot by hand-coding the algorithms in C using an editor and then compiling the code.
Instead, we used the Embedded Target for TI C2000 DSP (http://www.mathworks.com/products/tic2000/) to generate code automatically and deploy it onto the robot's control processor. In conjunction with Link for Code Composer Studio (http://www.mathworks.com/products/ccslink/) this product connects MATLAB and Simulink to the TI Code Composer Studio software development environment, which creates the real-time application. Using Real-Time Workshop (http://www.mathworks.com/products/rtw/) we generated C-code from the Simulink model and compiled and linked it using the TI compiler and linker. We loaded the code immediately into the robot's DSP, greatly reducing the time needed to fine-tune and test the algorithm.
We also developed a system to monitor and display the data, so we could compare the real and simulated data and check the functionality of the implemented controller. Figure 7 illustrates the complete rapid prototyping process for the robot.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_tic2000_w.jpg (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_tic2000_wl.jpg)
Figure 7. Rapid prototyping with the TI C2000 DSP. Click on image to see enlarged view.
To add to the DSP peripheral module support provided by the Embedded Target for the TI C2000 DSP (A/D converter, PWM generators, digital I/Os, and counters), we used Simulink S-functions to create additional sensor and communication interfaces and implement them as separate blocks. These functions included:
Digital inputs – This function reads the push-button values for robot operation.
Digital outputs
A/D conversion – Implementing extended A/D conversion made it possible to specify the prescaler, the conversion mode (either one conversion or the mean of multiple successive conversions) and the resulting shift.
Initializing and reading the external counters for the incremental encoders – The DSP has to control six DC motors simultaneously (four for steering and two drive motors). Its internal counters are not sufficient for the incremental encoding of all the motors. For these reasons, the output signals of the incremental encoders are evaluated using six type LS7166 counter modules and then read in by the DSP over a digital I/O data bus.
Operating and evaluating the data from the line camera – The line camera is controlled through digital outputs and the data is transferred through the synchronous serial interface (SPI). Evaluation of the received data, subsequently performed in the DSP, is also implemented through this block.
Serial communication – This function permits hard-wired or wireless communication between the robot and a monitoring PC or other robots. Figure 8 shows the custom blocks for the robot subsystems.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_supportblks_w.jpg (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_supportblks_wl.jpg)
Figure 8. Real-time support blocks for the F.A.A.K. robot. Click on image to see enlarged view.
We also reprogrammed the code generation for the processor's digital I/O to permit checking the assignment of the functions to individual DSP pins and settings of the corresponding DSP registers. There is a danger that multiple S-functions may attempt to use an I/O channel for different purposes, or that one S-function will overwrite the settings made by another S-function when writing to a register. To prevent this, the associated DSP registers are initialized in a central initPins function. During code generation, Real-Time Workshop TLC scripts generate this function in accordance with the S-functions present in the Simulink model. Each use of a DSP I/O pin is stored in a global structure. Once the code is generated for individual blocks, the system determines whether any conflicts have been detected. Using this method, it is easy to locate and correct conflicts, even in complex models. Figure 9 shows an example of the generated initPins function.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_initpins_w.gif (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_initpins_wl.gif)
Figure 9. Generated initPins function. Click on image to see enlarged view.
Communicating with the Robot
After the generated program is transferred to the DSP, the robot can execute the tested algorithm. To evaluate the data from the robot, we designed a communication mode between MATLAB and the robot that uses the serial interface via a serial cable or using radio modules.
There are two types of data transfer mode:
Online data transfer – The data transfer generally used to represent important robot parameters from each time cycle for monitoring purposes at the operating PC.
Offline data transfer – This transfer mode makes it possible to record data over a limited period for subsequent offline evaluation, as in the analysis of a specific travel maneuver. The number of signals to be recorded can be configured in the model. You can start recording with a trigger signal (recording trigger) and the data is initially buffered in the robot's onboard memory. Recording stops at the end of the buffer. A second trigger signal (transmit trigger) is then issued to start data transfer. The number of parameters and the buffer length are limited by the available DSP memory. The state diagram in Figure 10 illustrates the data recording sequence. http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_state.gif
Figure 10. State diagram for offline data recording. Click on image to see enlarged view.
The data is read into MATLAB through the serial port and can either be plotted in the FAAKComm tool (a GUI developed in MATLAB by the team) or used to animate the robot's 3-D VRML model. Figure 11 shows the FAAKComm tool displaying real data obtained from the real-time robot steering mechanism control. With the FAAKComm’s setting, it is possible to configure the serial communication parameters (port, baud rate, type, and number of transferred signals) and also the data display mode and automatic file storage of the received data.
http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_faakcomm_w.gif (http://www.mathworks.com/company/newsletters/digest/2005/sept/images/mb_faakcomm_wl.gif)
Figure 11. FAAKComm. Click on image to see enlarged view.
Results and Future Extensions
The integrated environment we describe here for developing mobile robotic control algorithms represents a complex platform consisting of multiple components. Engineers can use these tools for individual design stages such as model construction, simulation, code generation, HIL, and data analysis to accelerate the entire development process. The MATLAB and Simulink product families enable rapid development compared to designing “from scratch.” This results in a simple, highly flexible path for future developments and adding new functions.
We plan to extend our simulation environment with a working blimp model in the near future. This should enable us to derive and implement innovative strategies for cooperation between the ground-level and aerial systems. Further planned developments include simulating the embedded inter-DSP communication with the image processing system, along with automatic code generation for the TI C5000™ DSP.
更多... (http://www.mathworks.com/company/newsletters/digest/2005/sept/mobile_robots.html)