So far we have been talking about the three-link robot and the prototyping environment (PE) as separate subjects. In this section we will relate them by analyzing the problems that we have faced while designing and building the three-link robot, and how some of these problems could have been avoided if the prototyping environment was used in the design process. We will do that by addressing some of the design problems and what facilities the PE offers to solve some of these problems. Also we will discuss some of the problems that the PE -- with its current design -- will not be able to solve.
Most of the problems we had were due to the lack of communication between the different groups involved in the design. This lack of communication resulted in data inconsistency among the different groups. One of the problems was changing the mass of the links by the CAD/CAM group without notifying the robotics group. The reason for this change was that the links were too heavy to be driven by small motors. All simulations and benchmarking that were done by the robotics group were based on the original design parameters, and they had to repeat all these tests and simulations after they knew about these changes. The PE can solve this problem since there is an SSI at each subsystem. This SSI will report any changes in the design parameters to the CI, which in turn will report these changes to all subsystems that need to know.
Another problem was selecting the necessary motors to drive the robot links, and satisfy the speed requirements specified by the robotics group. All motors available in the market that can drive the robot links have high rpm. To reduce the speed, gears needed to be used at each joint. Adding these gears caused increases in the weight of each link, and again, the other groups did not know about this change until the assembly process was started. The part-ordering subsystem, suggested in the PE design, can solve this problem by sending a request from the robotics or the CAD/CAM groups to the part-ordering system asking for information about the available motors that satisfy the design requirements. This information would have informed the robotics and CAD/CAM groups about the necessity of adding gears at each joint earlier in the design phase.
The major problem we have faced in this project was the communication between the robot and the workstation. The problem was that the communication rate was too low due to the protocol in the operating system of the Sun Station which waits until a buffer is filled or timeout occurs before it accepts any readings through the serial port. We were able to solve this problem for the HP machine by changing the buffer size to be one byte, but we were not able to do that for the Sun machine. This problem caused the update rate to be as low as 30 Hz. Using The HP-720 we were able to reach an update rate of 120 Hz. However, we used the Sun machine even with its low update rate and we were able to control the three-link robot with an acceptable performance. The results shown in Section 6.3 were generated using a Sun Station-10 model 41, with update rate of 33 Hz.
This problem would not have been avoided even using the PE with its current design, since the PE database does not include detailed information about the platforms. This can be solved by adding more information about the platforms, or by calculating the actual update rate using each platform and put this value as a field in the platforms data file.
Another problem was to select a power amplifier to amplify the signals from the D/A chip to the motors. The power amplifier that we bought was not compatible with the motors we had, and we ended up using some power amplifiers from the ME lab to run our tests. This problem can also be solved using the part-ordering subsystem to select a suitable power amplifier given the motor parameters that we had.
The PE has some limitations with its current implementation. For example, there might be some data inconsistency due to the nonautomated SSIs. Currently, the SSI just informs the user of any change in the design parameters and the user makes the changes in the local files at each subsystem. This process is subject to human error and might yield an inconsistent situation. To solve that, all SSIs need to be automated so that the changes in the local data files of each subsystem are done automatically, and the user at each subsystem is notified of this change.
The automation of the SSIs requires that the subsystems used in the PE should be flexible enough to enable the SSI to make the necessary changes. In other words, it is not possible to make automatic changes if some of the design parameters are hard-wired in the code of the subsystem, because this will require changing the source code (which might not be available), and recompiling the program each time we need to change any of the ``hard-wired'' parameters. For example, we can not use a simulation subsystem that has a fixed update rate, since we will not be able to study the behavior of the robot under different values for the update rate.
This puts limitations on the subsystems that can be used in the PE. However, most of the ``general-purpose'' software robotic systems provide an easy way to alter any of the design parameters.