With our team’s Final Design Report on the horizon, we have all hands on deck for finalizing our prototype!

Our team has made major strides in our project and have integrated all components of our project together. Software developed by our software team has been integrated to our Raspberry Pi, with data being sent from our radar module. The LoRa chip has also been integrated to our Pi, with communication happening with the awearable project successfully! Device logs are also able to be sent through Bluetooth, which show data captured from the external radar and LoRa module. Our hardware team has also been hard at work, with our radar being successfully configured so that there is less noise in each frame and cars are more easily able to be recognized. Our team is also currently printing out the casing for our device, which is set to be complete in just days.

Figure 1: Team Road Response working hard. Teamwork makes the dream work!

Our team can’t wait to show off this prototype to the Florida Department of Transportation this upcoming Tuesday. We plan on giving an in depth presentation to our liaisons and sponsors, along with a high level presentation to various engineering students and coaches. We will even have a time period open to the public, so if you have been reading our blogs and are nearby the Reitz Union from 5-6pm this Tuesday, you should come check out our project!

As the finishing touches are being made to the prototype, the team took time this week to conduct testing both in-lab, collecting pulse data from the radar at various angles, and on-site, gathering mechanical measurements, configuring the optimal radar chirp, and working to finalize the communication interface with the Awearables team.

In the lab, we had the courtesy of Tim Ortiz to allow us to handle state-of-the-art devices. With these, we gathered important information on the field-of-view capabilities of our radar, and got to see exactly what each chirp was doing.

On-site, we planned to test our communication with the Awearables team, but we ran into an issue in connecting the antennas. The software team has worked hard to resolve this issue, and we’ll resume joint testing next week. Additionally, we spent time maximizing our radar chirp. The noise has been greatly reduced, and now we need only fix an issue where data points are vanishing past a certain range. Finally, we collected measurements on an FDOT-approved mounting stake and have modified the mechanical casing to match these constraints.

With Final Design Review just around the corner, the team will be hard at work to integrate the last pieces. We’re very excited to share the finished product!

Prototype Inspection Day (PID) is a day where we got to present our prototype in front of a panel of judges with a wide range of expertise. From this event, we gained valuable feedback that spawned important questions that we will share with you today.

How will we differentiate between a car and a bicycle on the road?

A car is bigger than a bicycle so there are more signals, or points, returned from a car. By recognizing these clusters of points, we can filter out smaller clusters returned from a bicycle.

How will we train road workers to utilize our device?

We will do a live and video demonstration that details exact setup and takedown of the device, as well as what to do in the event of an alert.

How will our device resist vibrations and storms?

The mechanical casing has a curved top to deflect rain and will be sealed via a screw in the bottom. The square hole will have a metal plate for cooling like a heat sink. Also, the case will fit snugly and lock into a stake to resist movement, rotation, and vibration. In severe weather cases, workers will not be active on-site.

Our team ran into a major setback this week as we received our PCB quote and learned that manufacturing our own PCB for this project will be infeasible do to shipping time and cost. Fortunately, because the backup radar has arrived, we will still be able to develop a complete product by the end of the semester though it will be a bit less ambitious than our previous design. This backup design will only be able to cover one direction (as opposed to the original bi-directional design) though we plan to allow the operator to toggle between parallel and head-on intrusion algorithm modes. The work that we have put into the PCB will be provided to FDOT as research that they may use to develop the product at scale in the future.

Figure 1: The backup module mounted on a tripod

In good news, our software team has successfully merged all of the product’s software components. The threat detection algorithm, LoRa communication protocol, and threat logging system now function as a cohesive program and are ready to be loaded onto the raspberry pi of our backup module. In the coming week, our team will have a fully functional prototype ready to be tested with the Awearables!

Above is the almost completed PCB Radar board. Due to some complications on Altium there were connections pathways that disappeared and have to be re-routed. This is the main reason I say the board is only 99% complete. This is the back of the board but if you look at the image below you can see the front view. The golden boxes connected to a line are the antennas that one of our teammates designed specifically for the board. It worked as needed in simulation but for RF antennas like this it is impossible to say if it will work well until you test it once it is physically build.

Outside of this if you look at the top image you can see how dense the area right under the chips are. It was particularly challenging getting everything to fit under there while leaving enough room to route both power and signal lines. Outside of this there was a lot of impedance matching for the signal routing.

As you can see there are a lot of holes on the board and those are vias that help connect routing between layers. This is everyone first time working on such a complicated board. The board is 8 layers and it is also a board where we have to deal with RF signals so there were a lot of complications and challenge’s we had to overcome. Overall, it has been a rewarding experience.

This week our team had our second Qualification Review Board of the semester. While our first QRB in January had a larger focus on our semester plan, this QRB looked more at our team’s current progress and how well we were following our plan. Our team was glad to share our progress with the board members and receive critical feedback.

Some of the most important feedback our team received was with our PCB board status. The completion of our PCB board is a crucial step to integrating other parts of our project together, and will allow us to get a quote from manufactures, which we need in order to finalize our budget. Our team has been working hard on completing our PCB schema and expect to have it complete by this Sunday.

Our team members working in software have also been working diligently as well. We were able to collaborate with The Awearable team this week to test out the range of our LoRa communication module. Our team is considering adding an Esp32 chip to our main design to help with testing and integration of communications. Our team’s threat detection algorithm is on track in development, with many of our test cases from our initial test bank passing. We hope to expand this bank in the future to test out situations with multiple cars and more noise. Our logging process is also on track with development, with our team able to showcase a retrieval of data from a simulated device with dummy data. Featured below is an example result from one of these demos, with a design optimized for readability of each alert.

Our software team has been working on 3 main components: threat detection algorithm, on-device alert logging and external access, and alert system-wearable communications. We are pleased to report great progress on all three fronts.

Crucially, our threat detection algorithm is able to accurately and consistently identify intrusion to an established parameter. As of recently, we also have an expanded, in-depth test bank to ensure the algorithm’s efficacy.

Our on-device logging process has changed slightly to a more efficient approach. Instead of storing an HTML file, the device will hold data in its raw form to be reconstructed into a user friendly format on the end-user device upon extraction. Our team has mapped the physical and software components that will be involved in this process to ensure proper implementation.

Lastly, our team has been working closely with the Awearable team on the development of our LoRa communication module. We have shared hardware requirements, both using the Adafruit RFM95W LoRa Radio Transceiver, as well as development libraries, primarily RadioHead. We have created packet structures for the two types of communication, heartbeat and alert, as well as transmission and receiver functionality. The latter is currently being tested by the Awearable team as our hardware is delayed. However, upon receiving our component we are ready for joint testing and, assuming all goes well, pivoting to security layer development.

Above is our preliminary design of the PCB. In the middle are two microprocessors and it will connect to a radar module.

We’ve been working hard on the radar device and the PCB is giving us unique challenges to solve. The first challenge is layer composition of our PCB. With high frequencies, we need a special material to maintain signal integrity. This material is a Rogers RO3003 and many fabrication companies don’t support this material because it needs advanced processing. Thus, we need to start emailing advanced manufacturers to get a quote that’s hopefully within our budget. Furthermore, our design contains eight layers that adds to the complexity.

The second challenge is tolerances, each connection in our design needs to be validated by a fabricator early enough to prevent design revisions due to inadequate specifications. This makes reaching out imperative to prevent redesign.

The final challenge is interference, with a completed board it can disrupt cellphone communication. Thus, we need to consider certain design elements to minimize interference. When the prototype is complete, we will test it for interference.

That is all for this week, more will be posted next week!