SPARK

Our Project

What is a Remote Firing System?

A Remote Firing System (RFS) is a system employed to safely and remotely initiate the firing of a payload (e.g. an explosive compound). Such a system will make use of a receiver to facilitate the energy transference to initiate the reaction with the payload, and a transmitter to generate and transmit signals to control the receiver. For example, special forces may use such a system to gain entry through a locked door (known as breaching); by connecting a receiver to an explosive compound, the special forces operators are able to take cover away from the door, and safely initiate it from a distance. Another use for a RFS is to safely dispose of IEDs (Improvized Explosive Device) by initiating the firing from a safe distance. The figure below illustrates the former example. RFS

What are the Problems with Remote Firing Systems?

Today's remote firing system presents a number of problems that needs to be remedied, most of which can largely be consolidated into two groups:
  1. The receiver size and weight.
  2. The system's lack of a software solution.
1. refers to the size and weight specifically of the receiver unit that is placed near the target of initiation. Due to the context a RFS is used, it's critical that the system is as lightweight and as easily managed as possible, so the operator can be better equipped in the field and use the system without second thought. The stakeholders who will employ this system are likely to carry a significant weight already, so alleviating this particular problem is a significant part of the project.

2. refers to the current paradigm of remote firing systems; a transmitter is used to control the receiver, but the extent of its functionality is that of arming the receiver, initiating an energy transferal, or setting a timer. In the 21st century, we believe we can do better.

Our Approach to Solving the Problems

We organised ourselves by adhering to the Scrum project model; by running two week sprints we were able to iterate often on the various parts of the project. Requirements, risks, development, testing, and evaluation were addressed frequently to ensure we were developing the right solution. Due to the covid-19 situation, we had to get creative and frequently utilize tools such as Google Hangouts, Slack, and online drawing & diagramming tools. The figure below illustrates how we used Scrum to guide our daily, weekly, and Sprint workflow.

Sprint Events

Solving the Problems

To address, 1. we had to select electrical components that were smaller than the ones used in today's remote firing systems, and subsequently construct a smaller PCB. However, this had to be done without sacrificing any of the existing functionality; in fact, for our solution, more functionality had to be added. With a smaller PCB, a smaller casing could be constructed, but this too couldn't afford to sacrifice any of the ergonomics and physical traits of existing remote firing systems -- this meant the casing had to adhere to ingress protection standards, be resistant to a large and varied selection of weather conditions, and be durable enough to not break upon hard impacts, among a myriad of other concerns.

To address 2. we had to develop a user-friendly software solution that could easily be used by the operator of our system, and also facilitate the means by which it could be integrated with existing military systems. The primary purpose of this software solution was to aid the operator in their decision making and tactical awareness, ensuring that when they for example, either arm, initiate energy transferal, or set a timer, that they could make these choices confidentely and with no fear of mistakes.