DieselZilla Attack Drone (DAD) is a project to enable high school students to manually fly small drones to attack DiezelZilla. In the 2017 California State Fair, DAD will be one of the exhibits with live attacks.
The entire project consists of several main pieces. The following is a proposed plan, but it may deviate due to technical reasons.
LEDs (most likely 12V truck markers) will be magnetically attached to the shell of DieselZilla. Each one marks one of the hit points of DieselZilla.
To facilitate “shooting” using a on-board camera on a drone, these LEDs blink with specific timing. The general pattern is all-on, all-off, one specific on.
The all-on phase performs two functions. First, it allows the “gunner” to see the points that can be aimed. Second, it provides sync timing to the second phase.
The all-off phase is a spacer to separate the first phase from the second phase.
The second phase, with only one LED turned on, allows software to analyze the video feed of a drone and determine which (if any) kill zone it is aiming at. The video feed analyzer is time synchronized with the LED controller.
After a delay, the controller returns to phase 1. However, the LED lit in phase 2 moves on to another spot on DieselZilla. Eventually, all the kill zones get cycled through.
The video feed analyzer taps into the video broadcast of the camera of a drone. This analyzer is time synchronized with the LED controller so that the timing of the blinking of the LED is known to the analyzer.
The main purpose of the analyzer is to compare frames of the video feed and look for the all-on phase. Then the analyzer will look for the specific LED that is lit in the second phase. If a recognized LED is within a small area of the image, then it is considered aligned.
An alignment is not considered a “hit” because we do not want to assume just hovering and overlooking an LED to be considered a hit. Instead, an app is used for fire control.
A score board program is used to update a score board in real-time. The score board itself is web-based so that it can be viewed remotely.
The coordinator is a supervisor program that coordinates the LED controller, the video feed analyzer, the score board program, and the fire control app.
This is the Android program that is installed to a handheld device that a “gunner” uses to control virtual firing of a drone.
The value of an app is the reason why it is installed in the first place. In this case, the value of the fire control app is to enable the DAD demonstration. The DAD demonstration, in return, has a value of entertainment and drone piloting training.
It is important to keep track of the values of the DAD demonstration itself because the fire control app is one aspect of it. A component of a project inherits values from the project itself.
A UML actor is an agent outside of the system being specified that can interact with the system. In the case of the Fire Control App, it is important to think about what the “system” is. Is the system just the app itself? Or, is the system the entire DAD system?
For software specification, we consider the app itself as the “system”. This means we have more than one actors.
The first actor is easy, the “gunner”, a user who controls the virtual “firing” of a drone.
The second actor is the coordinator of the DAD system. The fire control app needs to communicate with the coordinator because the fire control app is, for the most part, a dumb terminal to the DAD system.
What actions of the fire control app supports its values and purposes? Recall that a use case serves at least one value all by itself.
The first and most obvious use case is “fire virtual gun”. Both actors connect to this use case because this use case requires the app to interact with both the end user as well as the DAD coordinator.
The second use case involves only the DAD coordinator to use the fire control app to update parameters in the fire control app. This use case can be named “update parameters”. This includes the amount of time remaining, aim status, “ammo” status, drone health status and etc.
One requirement of the fire control app is low latency. In other words, the lag between a user clicking fire and the DAD coordinator registering the event should be minimized.
Another requirement is integrity. We want to make sure the DAD coordinator cannot be tricked. For example, the tracking of shots left, score, and other status should not be hackable!
We also want a reasonable range of wireless operation so that several teams do not have to stand in close proximity during a competition.
There are 3 ways for the fire control app to communicate with the DAD coordinator.
4G (cellular) is ruled out due to the unreliable communication speed. This mode of communication incurs latency because of several reasons. First, 4G itself is not a high bandwidth communication protocol. However, the unreliability (in terms of speed) comes from the all the hops of routing to go from a mobile device to the notebook computer running the DAD coordinator.
Bluetooth is an attractive alternative because it is a direct communication channel between a mobile device and the notebook computer. However, Bluetooth communication (class 1) has a short range.
Wi-fi is the best choice because it has the locality of Bluetooth but a good bandwidth and lower latency. It also ensures a certain degree of integrity by using WPA encryption (so that only registered mobile devices with the pass-phrase can join the network).
A mock sequence is a simulated run of a use-case. Different sequences should be documented to include the handling of error or exception cases.
A mock sequence is a log of actions from the perspective of the system as a whole. It is usually started by one of the actors of a use case. Each actor is represented by a time “lane”, the system has its own time lane. Interactions are represented by arrows going across the lanes.
Because the DAD coordinator is an active actor, meaning that it can initiate communication with the fire control app, we need to include mock sequences representing transactions started by the DAD coordinator.
It is also important to include sequences from the perspectives of the end user. For each press of the fire button, what can happen regardless of how the “back end” is designed? This includes scenarios of running out of ammo, having a hit, and etc.
A key design decision is to figure out how much logic should be in the firing app.
On one end of the spectrum, we can put as much logic in the fire control app itself. This includes the counting of remaining ammo, inquisition of hit/miss status for each shot, and etc. A potential problem with this approach is miscommunication between the fire control app and the coordinator causing problems that cannot be easily fixed or reset.
On the other end of the spectrum, we make the fire control app as dumb as possible and push all the logic to the coordinator side. This approach increases the amount of traffic between the two mobile device and the notebook computer running the coordinator program.
Unlike Google Doc, the fire control app has relatively little local processing and screen update. As a result, the second approach is preferred unless there is data showing Wi-fi bandwidth (communication speed) is not sufficient due to increased traffic.
The use of wi-fi means networking protocols are used to facilitate communication. This is another advantage over Bluetooth because the use of TCP/IP (instead of Bluetooth) means any number of logical connections can be made using TCP, or the use of UDP can be used for quicker communication that has no built-in delivery guarantee.
The classes corresponding to TCP or UDP based communication do not generate or listen to events.
The user experience should resemble what a gunner experiences. We assume the gunner can overlook a large monitor to see what the drone is seeing, so there is no need to relay the video feed on the mobile device. This saves a good amount of traffic as video feed is often bulky.
The fire control itself may include a “safety” like an actual fire controller. This helps prevent triggering shots accidentally. The fire control itself is represented by a certain area on screen. Tactile feedback can be useful.
The fire control app may also include an ammo count display. This helps the gunner decide on firing strategies depending on how much virtual ammo is left.
An important part of developing software using OOP (object-oriented programming) paradigm is to identify the objects! Some objects are obvious because they correspond to visible on-screen constructs. These objects include buttons, text displays and etc.
Some objects are not visible. In the fire control app, the firing mechanism is an object because it has multiple states:
A state diagram graphically represents the states and their transitions. Note that a state diagram is not a flow-chart! A state diagram serves a purpose that is quite different from that of a flow-chart.
In a state diagram, a “state” can be explicitly represented by a private member (often as an integer).
A “transition” has several components:
An “event” of a state diagram corresponds to an actual event. In our example, the “pull” event corresponds to something like a button-down event, and the “release” event corresponds to a matching button-up event.
The work that is done by an object (via method calling) is done by a thread. Different threads perform the work of an object. For example, a background thread can update the state of an object, while a main/UI thread queries the attributes of an object and reflects them using views in an activity.
To sum up the concept of an object: it represents a construct in a program that has a state, listens to one or more events, and has actions to perform.
TCP and UDP connections/communications are facilitated using the ServerSocket, DatagramSocket and Socket classes. These classes do not have any on... event handlers, and they do not generate events, either.
In order to utilize state diagrams, events related to network communication require some special considerations. First, if the app expect incoming transmission, a dedicated thread should be used to wait for the incoming transmission. This is because the method to accept an incoming transmission is “blocking”. If this is done in the main/UI thread, then all user interaction will be frozen until there is an incoming transmission.
Upon the reception and processing of network communication, the communication thread needs to create events to let objects change states. This can be done by first considering the data and logic corresponding to an aspect of communication an object. Then turn this object into a model where there is a clean interface for an adapter to connect to.
Any network communication object that receives needs to track listeners to the logical messages received and call the corresponding methods of such listeners when messages are received. Any network communication object that transmits needs to publish methods for the transmission of such messages. This allows an adapter to register as a listener in case messages are received, and instruct the object (model) to transmit when that is needed.
An object represent an instance of a model. It listens to events, and it performs actions. Separating a model cleanly from views makes it flexible to attach a model to alternative views with no change of model coding. An adapter is used to connect a model to a view. This way, associating a model to a different view only requires writing a new adapter class, but it requires no change to the code of the model nor the view.
This architecture enables code reuse and modular coding. The clean interfaces of models and views also make it easier to split a project into multiple parts where each part is developed simultaneously by different developers.