Optimization
Fig 1. - Our Dual Servo Hardware Design
Hardware
One of the major considerations we took on the hardware side of our project was the usage of servo motors with internal closed loop control to allow for the accurate measurement of bearings for power as seen from one of our modules. However, due to the functionality of a servo, that feedback of the precise position is only used internally to arrive at that position, and cannot be fed back to the arduino for continuous angle measurements.
The consequence of this is that we must wait for the servo to arrive at a target position before we can confidently relate the power received to its reported position, and this ends up slowing the scanning rate significantly with higher angular precision. For instance, it takes much longer to get from 0 to 180 degrees in 20 steps than it does in 4, and that difference hinders our ability to track targets in motion.
Our original plan to have a continuously rotating antenna would have been able to avoid this issue, as that system would have used a stepper motor to consistently rotate the antenna in a single direction 360 degrees, avoiding the delay of changing directions, as well as using a magnetic encoder to have continuous monitoring of the angular position of the antenna external to the motor itself. However, with our current system, we have decided that we can find a middle ground between small steps for angular precision, and large steps for system speed. Without the installation of an encoder, we can interpolate between moderate-sized, well-timed steps to improve the resolution of our system, and still preserve scanning speed. Additionally, the usage of a high-voltage battery that is at the upper limits of our hardware's operating capacity maximizes the speed of our servos.
Data Processing
Fig. 2 - Normalized Simulation Results of Polar Plot Outputs
Fig. 3 - Animated Simulation Data for GUI Development
Our data processing for the outputs of our Dual-Servo modules has largely been pioneered in MATLAB. Algorithms to distinguish sources from one another have shown some limitations with only 2 modules if multiple sources lie in the same plane as the modules. However, this ambiguity disappears with additional modules, and the ability of the SDR to distinguish sources by frequency, and usage of power estimation techniques also show promising applications. Once sources can be distinguished from one another, using the positions of each module and the bearings of peak power as inputs, MATLAB can solve a system of linear equations to return the estimated 3D spatial position of the source.
To support the progress of the GUI, MATLAB was also used to create a program to generate and plot sample data for multiple sources moving through space with data we wish to display in the GUI, such as frequency, estimated power level, and approximation accuracy.
While the methodology for data processing has been realized in MATLAB simulations, due to the lack of Computer Engineering experience, moving to Python for real-time data processing our module's outputs has had a substantial learning curve, and has been the slowest area of progress.
Visualization
In the Milestone 3 update, the Flock Force software included an indoor wireless localization system using Wi-Fi fingerprinting, although it was still producing issues. We have decided to pivot away from the indoor wireless system both to streamline our system and to dedicate our time to enhancing the outdoor visualization. As a result, the indoor localization team has been transferred to the visualization team. This tradeoff has prioritized the overall success of the project, as well as the importance of quality in the visualization.
The visualization system has changed from MATLAB viewing, to Python viewing, and has landed on a Cesium Ion model embedded in a JavaScript / HTML system. This enables us to connect to the output of the hardware system and layer additional filtering of data (currently using a JSON file of test data) and more visualization options. By connecting to Cesium's database, we are able to use their updated maps and visualization systems. Additionally, using Cesium's plug-ins would enable us to have better cross-platform accessibility.
This visualization method is presently the most effective mode of delivery for our project, especially given the time restraints due to transitioning the team. For a proof-of-concept stage demonstration, this is a clean and effective display. For a test run with a local users such as the Stevens Police or the Hoboken Police Department, we would be able to the enterprise package offered by Cesium. For a full software release, we would like to be more autonomous and use our own proprietary engine. This would allow us to have more control. This may include using an API from another company with more resources.
GUI
In Milestone 3, the Flock Force GUI was a webpage running on a localhost server using JavaScript and HTML. As other parts of the software and hardware pivoted, the GUI team also decided to shift in a new direction to optimize the performance and functionality of the system. Given that the signal data is collected in a MATLAB file, the team considered the trade-offs in using JavaScript vs. using Python for the graphical user interface. While JavaScript is more geared towards coding webpages, Python has more existing libraries that would make the link to MATLAB much smoother. So, we began on development for a new GUI that would use the GUI tool Tkinter in Python and also relevant MATLAB libraries.
Below is a screenshot of the current state of the newly developed Python GUI:
Fig. 4 - aaaaaa
Next steps included importing the MATLAB data that would be accessed through the "File Explorer" button. The team also would need to program the functionality of the "Frequency", "Power", and "Location" buttons to filter the signal data. Finally, although the GUI had a 2D map present, it would be ideal for the map to be 3-Dimensional to maximize the visualization potential.
As one member worked on developing these next steps, another member focused on further optimization of the GUI for the system. When researching a 3D map API or application that would help us visualize signal data on a map, the team came across Cesium Ion. This engine has a lot of the tools the GUI requires natively and it is a very recent 3D map, making it more detailed and suitable for visualization. The only problem was that to use this application, we would need to revert back to JavaScript as that was what this tool was set in.
Although the tradeoffs we considered before helped us initially choose Python over JavaScript, the state the team was in now helped determine that JavaScript would be best after all, especially considering how vital it would be to get the Cesium Ion application working. On top of that, the team found that the MATLAB file could be uploaded as a .JSON file instead of a .m file, which would make the data compatible with the JavaScript code. Below is a snapshot of the GUI we will be using to both visualize signals and display their data:
As you can see above, the map is both more detailed, and also 3-Dimensional. Furthermore, the screenshot above displays a red dot a little to the left of Howe Center to represent a detected signal. Next steps are similar to the Python version of the GUI including the addition of buttons to filter data.
Overall, there were several iterations of the GUI the team went through but the current state is the optimized version, combining all the team's critical needs and requirements for the system.