Review of Group B Preliminary Design: Remote Sensory Vehicle
Jeremy Coriell
Ha Le
Jeff Phillips
Overall Design
The overall design of the
Remote Sensory Vehicle project is ambitious.
There are many separate
subsystems, each of which requires a significant amount of design and
implementation. Adding to the overall
project complexity is the requirement to integrate each of these subsystems
into the final project. For our technical
review of the project, we look at each subsystem or functional area separately
and then look at the integration of the overall project. The areas we examine are: movement, sensors,
RF communications and video.
For the movement features of the project, we are specifically interested in the interaction between control modes (manual vs. autonomous) and how the system manages these transitions. We are also interested in how the servo motors are controlled in each situation. Finally, we look at how the manual control signals are generated.
From preliminary design description, it is not entirely clear how the transitions happen between manual and autonomous control. This functionality should be specified for all possible conditions, especially since the mode change can be triggered manually or automatically. Also, care should be taken to ensure that the servo motors are never driven simultaneously by conflicting signals.
Another issue regarding autonomous mode is how the vehicle goes about recovering a signal control signal that has been lost. The design states that the vehicle will reverse direction in an attempt to regain the control signal. This implies that there must be some notion of reverse. How is this achieved? Is a history of past motion maintained to allow for backtracking (perhaps a technically challenging approach)? What if the vehicle is powered up initially and there never is a command signal from the beginning? This particular functionality needs to be better defined.
Finally, manual movement commands are sent over existing the RC link. Originally, the user would manually manipulate switches to send the signals. Now the XSV hardware is reading keyboard input in order to send the same signals. How faithfully does this mimic the original controller? For example, how long does a single command stay in effect? The original controller was a switch that would be shut for a certain amount of time and then released. Can such events be reproduced or will the output from the XSV hardware resemble a series of pulses instead of a steady signal?
For the sensors portion of the design, we are specifically concerned with the use of the sonar rangefinders. Our two main issues are interference and electrical characteristics.
The sonars are arranged in two banks of three transceivers each: one bank in front and one in back. The design carefully addresses the issue of interference between individual sonars in a bank, but interference between banks is not considered. Is there a possibility that a pulse from one bank could be detected by the other, especially in a small, crowded environment? One simple way to prevent possible inter-bank interference is to use a bank-enable signal. Since the sonars are used for collision avoidance, only the bank associated with the direction of motion could be active. Since forward and reverse motion is mutually exclusive, the sonar banks are guaranteed not to interfere.
Finally, the electrical parameters of the sonars are mentioned in the design, especially with regard to power consumption. The specifications for the sonar indicate that the device can experience maximum currents of over one amp. This high current must surely be limited to a short period of time (e.g. when firing a pulse) and should not be a significant concern regarding power consumption. However, this high instantaneous current could result in a significant drop in power supply voltage. Such fluctuations in the power supply can seriously affect the overall system. To avoid these potential problems, appropriately sized capacitors should be used on the power supply to the sonars. In addition, adding these capacitors will affect the rate at which the sonars can be repeatedly fired. This increased time delay should be considered.
RF communications between the vehicle and the base are implemented with the Virtual Wire Development Kit. Since this link is heavily relied upon for two-way communications with the vehicle, it is important that it works properly. Our concern is that the Virtual Wire system is not being used to its full potential and a lot of design effort is being put into dealing with issues that the Virtual Wire system can automatically handle.
One of the issues that the project design deals with is the collision of packets over the RF link. In general, this issue is handled by the Virtual Wire system’s firmware implementation of its radio packet system. The details of the packet system are dependent on the operating mode of the Virtual Wire system, but packet collision avoidance can be had for free.
Also, line-powered RS-232 transceiver is used to interface to the Virtual Wire board is unnecessary. The board itself has such a chip which can be removed from its socket and jumpers can be used to connect the signal paths directly. This would allow direct logic-level interfacing to the Virtual Wire boards.
The final area we cover is the decoding and displaying of the video signal. Obtaining the decoded (i.e. digital) video stream from the vehicle seems to be a straight-forward matter. However, appropriately converting and displaying this signal may be a problem.
The first issue is the process used to convert the YUV signal to RGB. The method described in the project design may be prohibitively expensive in terms of the amount of time needed to convert an image frame to RGB. One possible approach is to sacrifice some precision of the pixel data and use a static lookup table to perform the conversion.
Once the image data is converted to RGB, the issue of displaying it arises. The project design document mentions the possibility of double-buffering the image data. However, if one of the expansion headers on the XSV board is being used for I/O, the SRAM bank on that side cannot be used. That leaves only one SRAM bank, which doesn’t allow simultaneous read and write operations. One possibility is that the flash RAM could be used for buffering as well, but it may interfere with the serial port since they share electrical connections through the CPLD.
Our concern with overall system integration is specifically about the interfacing of the five 8051 microprocessors. There is a protocol in place for handling state of the system and the flow of data between processors, but it seems quite complicated and may be sensitive to timing issues. We think that in the end, the system could work as described (we could see no obvious flaws) but perhaps a different approach to dealing with the inter-processor communications could be used. One possible alternative would be to use the I2C protocol for communications.
In general, the project is ambitious but achievable. There are specific issues regarding motion, sensors, RF communications, video display and system integration. Most of the issues we have raised are easily addressed and do not reflect any shortcoming of the design. There are a few more difficult issues, especially regarding the video system, but we are confident that Team B will persevere in the end.