Blog Posts – ay2526team06

Week 5: PCB Challenges

Published:February 15th, 2026

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!

Week 4: Developmental Process and FDR Prep

Published:February 8th, 2026

Category:Spring Semester

This week, our team spent time working separately on hardware and software development. The hardware team is working diligently on the radar PCB schematic, integrated antenna, and battery power specifications. The software team is working just as hard on improving the threat detection algorithm, creating a means to transfer real-time radar data to HTML, and establishing a communication interface via LoRa.

Figure 1: Altium Schematic of Radar Microcontroller

Additionally, the team has begun to prepare for the final design review. We’ve outlined the various volumes of the report, covering specifications from functional decompositions to legal evaluations. As we begin to finalize our product, we will further detail the contents of the final design review.

Overall, it has been a productive week for the team, and we are excited to share the future developments of our project!

Week 3: QRB 1

Published:January 30th, 2026

Category:Spring Semester

This week was our first Quarterly Review Board of the semester! The team was excited to present our progress, and we received a myriad of valuable advice from our coaches during the event. Some of our most important takeaways are that:

We need to order the parts for and complete the PCB as soon as possible because that is the biggest bottleneck in our critical path.
We need to expand our test bank to evaluate the product’s efficacy in different environmental conditions
And moving forward, we need to incorporate collaboration with the Awearables as a core component of our presentations

Over the next few weeks, we will focus on addressing this feedback and remaining on pace to complete our project by the end of the semester.

Figure 1: Project Critical Path

Week 2: Long-Range Detection Strategy and More Testing

Published:January 25th, 2026

Category:Spring Semester

This week, our team took a deeper look at how we could meet our long-distance threat detection requirements. Primarily, we evaluated several higher-performance options in the millimeter-wave radar chip product space. Our final contenders were the AWR2944P chip, or running a cascaded architecture with multiple AWR2243 chips that effectively allow multiple radar front-end chips to be synchronized together to increase antenna and power gain, improving overall performance. The main issue with both setups is that the antenna and aperture must be designed, and for the cascaded design, there is increased complexity to make the devices work seamlessly. There is an option to buy packages that include these devices, or similar devices, in evaluation-ready or test-ready form, but the prices of those modules are high and not practical for high production reproducibility or running multiple setups. Thus, our team decided that it would be best to diverge our efforts. One subdivision of the team would work on designing and developing the cascaded setup and antenna design, while another sub-team would hone in on integrating our existing radar technology into a finalized prototype. That way, if the cascaded design works, we can later integrate it into a more complete package, and if the cascaded development does not fully finish in time, FDOT can still use a reliable product and have a jump-start on further development if needed. This proposition is pending official approval from our liasion when we meet with them this upcoming week.

Figure 1: Capturing additional radar lane data of moving vehicle in Garage 14 at UF

Alongside these critical decisions, we continued to perform field testing, this time atop Garage 14 at UF using our current testing prototype (AWR1843AOP-based). This time, we set up cones to simulate lane boundaries and drove a car on multiple sides. This setup increased the volume and variety of data that will be passed on to the software team to further help refine our clustering, tracking, and ultimately, threat detection logic.

Overall, this week helped solidify our grounding in our technical direction and risk-management strategy in the second semester of IPPD!

Tagged as: #cascadedradar, #harryzarcadoolas

Week 1: WE ARE BACK

Published:January 16th, 2026

Category:Uncategorized

After a long winter break we have finally started getting back into the project. There have been a few challenges with the main one being the fact that we have a new coach. After a long team meeting with her we got her up to speed on where we are at and what we are planning to do in the future. As a team we are looking forward to the new perspectives she could provide for this project.

Other than that a new semester meant a new schedule for everyone. This means we have to reorient ourselves to everyone’s new schedule so that we can setup our weekly meeting times. We are waiting for the end of Friday to do this as we must wait until the end of drop add.

In some more exciting news we have narrowed down our choices for the longer range radar in our design. We are in the final process of choosing the best one from these options. Lastly we are hoping to buy our communication module by the end of this week so that the software team for the communication with the wearable can start developing and polishing up their code.

Week 13 – System Level Design Review

Published:December 5th, 2025

Category:Fall Semester

This week our team had our official system level design review! This event represented the culmination of the work we have done in this fall semester. We showcased our development of radar testing, algorithm creation, hardware planning, and design integration to have a comprehensive system-level package that ultimately helps FDOT in reducing roadside worker injuries.

Our team was able to deliver a full overview of our intrusion detection device, covering system architecture, hardware and software design paths, technical performance measures, and results from our early range radar testing. We showed the radar pipeline and how it processes real time point cloud data into clusters of objects and then begins to identify possible vehicle threats to a construction work zone. As we continue to improve on this, we were excited to display a solid picture of where our system lies now.

Figure 1: The members of Team Road Response at the start of our SLDR presentation.

The presentation had a lot of positive feedback from our sponsors and IPPD faculty. Reviewers highlighted that we had clear communication and clear subsystem interfaces with thoughtful justifications behind our design decisions (e.g. radar selection, clustering strategies).

With this feedback, we also received recommendations to help guide our spring development. Some feedback included that we should continue to tighten our threat detection logic, refine performance metrics like detection speed and false alarm rate, and conduct more radar testing for different scenarios. It was also noted that we should begin our PCB development as early as possible to get a head start on any integration challenges that we might face. Altogether, these insights and the experience were extremely valuable in reflecting on our design thus far and having a game plan for our prototype in Spring.

We appreciate everyone who attended the event and we look forward to keeping up the momentum!

Week 12 – Data Analysis and System Level Design

Published:November 21st, 2025

Category:Uncategorized

With the onsite testing done last week our team was able to extract real data radar that is applicable to our project. Major accomplishments were made within this project, as we can now combine our hardware and software to detect objects and their speeds. Below this paragraph is a side-by-side comparison of our object tracking algorithm on a car entering a lane-closure work zone. Note that some static objects are being tracked alongside the moving car. Some of our team’s next steps are to improve our radar chirps and algorithms to reduce noise and unnecessary objects.

Real time object detection

Along with these achievements made, our team is also preparing for our System Level Design Review(SLDR) event coming in early December. Within this event we will be reporting on the overarching systems of our device, current progress with development, and what we hope to accomplish during the spring semester. This week we were able to refine our presentation and have it reviewed amongst other IPPD students and coaches. Our team is very exited to host this event and share our progress with FDOT!

Week 11 – On Site Testing

Published:November 14th, 2025

Category:Fall Semester

This week, our team went on-site to the FDOT Operations Center to collect data from our radar sensor. We plan to use this data to improve our hardware setup to maximize the range and accuracy of vehicle detection, as well as improving our software to maximize accuracy and make strong predictions of each vehicle’s trajectory.

The videos below demonstrate a vehicle intrusion during a lane closure, where the test vehicle first heads in the opposite direction on the correct side of the road, and then comes into the lane closure on its way towards the radar. Each video can be played side-by-side to watch the data collected on the radar as the test vehicle travels in real-time.

Week 10 – Visualizing the Radar

Published:November 8th, 2025

Category:Fall Semester

This week, we were able to start gathering data from the radar device and visualize the data on a graph. Below is a video that demonstrates how the radar picks up an object from a distance. Note that the orange dots represent a point on a object that the radar detects.

In the video above, you saw a spike with a lot of orange points and that represents a cardboard box that we move in front of the radar. We used this demonstration to provide clarity in front of eight judges whom provided feedback during prototype inspection day.

Justin performing the box demonstration in front of two judges

During the event, the judges pointed out that we had a lot of noise in our demonstration. So, we need to figure out a way to filter out the noise in order to detect cars accurately. Furthermore, they suggested that we should implement “fake noise” into the radar device itself to test our car detection algorithm. This would ensure better accuracy in noisy environments.

Harry explaining on how we chose the radar device

In all, this week proved to be a big step in our journey to create a device that alerts workers of traffic hazards ahead of time to save lives.

Week 9 – Preparing for Prototype Day

Published:October 31st, 2025

Category:Fall Semester

This week we finally got to interfacing with our radar module. We had a couple of set backs that have delayed us fully interfacing with the radar module so although we can now flash it we are unable to read data from it. To remedy this we ended up purchasing a second UART to USB adapter and once it arrives we should be able to read the radar data.

We also went out to FDOT operational facility to start some initial testing. Because we could not fully interface with the radar it was not as fruit full as we would have liked it to be but we did get some additional documentation about lane closures from FDOT while we were there. Overall, even with these setbacks we should be able to achieve our goal by prototype day.

UF Resources

Campus

Website