Brian
Lenz
Mark
Christiansen
Adam
Prewett
CSE
477
May
3, 2001
In this document, we will be reviewing the design of the Etank. We will point out the parts of the design that we like, as well as the aspects of design that we feel may need improvement. Firstly, we will review minor details of concern such as parallel port communication, power consumption, component communication, compass polling, serial communication, and RF frequencies. Secondly, we will cover more involved issues including the control implementation and the testing environment. Finally, we will conclude with a summary of our opinion of the project.
In this section, we will first go over some minor design issues. After that, we will go into more detail for the control implementation and the testing environment.
In the minor design issues section, we briefly discuss some aspects of
the Etank that could use improvement or further clarification.
In this section we discuss parallel port communication, power
consumption, component communication, compass polling, serial communication, and
RF frequencies.
We are concerned with the assumptions made regarding parallel port
communications. Under the current
design, a signal is kept on the port until the next packet of information is
sent. We believe that it would be a
cleaner implementation if the inputs taken from the parallel port were buffered.
This would prevent the application from relying on a persistent signal
from the parallel port. Although
this matter may seem trivial, we feel it is a safer method of communication.
Another issue is the power consumption of the system.
The sonar, PIC processor, compass, and oscillator are connected to one 6V
battery. It is not clearly
specified which type of 6V battery the Etank will be using.
It is also not specified as to how much current these devices will be
drawing. We are concerned that
these devices, all sharing a common battery, may drain the battery quickly.
Additionally, the methods of dividing the voltage have not been
completely specified for each device. It
might be desirable to have multiple batteries to power this portion of the
system.
Another minor issue we found with the Etank pertains to the communication between the remote and central modules. There are two paths of communication between the remote component and the central component of the Etank. Our initial reaction was that it would be a cleaner design if the two different components were only communicating over a single RF link. If this were the case, the tank’s remote control unit would not be in use. However, interfacing to the current remote control for the tank is relatively simple. As a result, we realize that it would be easier to implement the control of the tank over the existing RF link. Thus, using two RF links is a valid solution for a class prototype. In a manufactured product, however, we feel that reducing the communication to a single RF link would provide a more robust solution.
The PIC on the remote module is specified to continuously poll the compass. However, the frequency of the polling has not been specified. We feel that this frequency needs to be more completely specified in order to define the performance of the remote module. If the compass polls at a slow rate, the compass will not update frequently enough to notify the central module of the current heading. We feel that the compass should be polled at a frequency of at least 5 Hz in order to be able to transmit data to the central component sufficiently fast.
The serial port communication needs to be specified. In the preliminary design package for the Etank, two methods of serial communication are discussed. One of the two methods must be chosen, eliminating the other serial communication method in the design package.
The RF frequency of the existing tank remote control was never specified in the document. We feel that the group should take care in ensuring that there will be no interference between the control RF link and the data RF link. If the two links interfere, then the frequency of the data RF link should be modified since the remote control frequency is configured in hardware.
The first major design issue is the control implementation of the Etank.
We believe that the foundation for controlling the Etank seems well
planned. However, the response from
sensors and the ensuing behavior needs to be more completely specified.
Additionally, it is unclear how the Etank will behave when it receives
information from the sonar that it is approaching an obstacle.
The first major control issue of the Etank resides with the turning of the tank. If the tank is instructed to turn a certain amount and then stop depending on the compass output, the tank is guaranteed to over steer. The compass response and the processing delay are much slower than the tank movement. In order to compensate for over steering, the tank may then turn the opposite way. Just as before, the tank could easily go past its desired turn angle. The tank could continue turning past its desired turn angle for an indefinite amount of time. In order to correct the tank from over steering, we suggest turning the tank in short bursts. Moving the tank in short bursts will hopefully give the Etank enough time for the compass to adjust and for data processing to take place. Doing this will give the user more controlled movement over the Etank.
There also seems to be some ambiguity to the specification of the
Etank’s movement. In one portion
of the design package, it is stated that the tank would be instructed to move a
set distance or angle. However,
elsewhere in the document the tank is specified to keep moving in a specified
direction until the user issues another command.
This feature needs to be more completely specified in the final design
package. We believe that specifying
a distance or angle for the tank to move is the specified and intended solution.
We also believe that this is the most desirable specification for
movement of the tank.
Through talking with the group members and reading the preliminary design
document we found very little reference to the environment that the Etank will
be operating in.
The complexity and accuracy of
components in the design rely greatly on the environment that the Etank will
reside in. If it is an open 15’
by 15’ square, little consideration needs to be made about how the tank will
deal with obstacles. If it is an
area with walls or other obstacles the Etank needs to be able to determine how
to deal with them. For example, the sonar only works within the range of 6
inches to 35 feet. If the tank
operates outside of this range, the sonar unit will fail.
In addition to pure technical design issues, the environment should be
specified since it is an integral part of their goal:
Using
Etank allows students to learn basic programming concepts by controlling
movements of a toy tank that is able to draw different shapes on a surface.
We feel that the drawing surface
needs to be specified. If the
surface is to be made of paper, the tank’s gliders must not interfere with the
drawing surface. Additionally, we
feel that the drawing object needs to be determined.
This is an important part of the design that needs to be addressed.
The solution to this problem is to completely specify an environment for the Etank. We suggest designing an open 20’ by 20’ square with a wood framed border that the tank can maneuver within. Introducing obstacles and irregularly shaped walls adds another level of complexity to the controls of the tank. If the tank is going to be used as a drawing tool then it would also be easy for the floor to be covered with a sheet of paper so a pen or brush could be attached to the tank. Within this specified environment the only critical consideration would be how to handle to the case where the tank runs into a wall and the sonar becomes out of range. This could be easily fixed by sending warnings to the user when the tank gets within a couple feet of a wall.
Overall, we feel that the Etank was planned out very thoroughly. It is apparent that much progress has already been made to help assure the Etank’s success. The modularity of the Etank will help the group members distribute the work evenly during development. It will also be helpful for testing the system once it has been implemented. Although the communication scheme is very involved, the members of Group E seem to be well on their way to making this project a success.