This week we received all of our parts in the mail, so we are moving forward with testing and working on integrating as much as we can. We have been working in getting coherent data from the sensor and using that to inform the filter for the data. Since we have the mount, next week we will be able start testing with data from both sensors in the same arrangement that we will likely use for the final. The survey for the LED communication is almost done, so by Monday we will be able to distribute the survey and make a final decision on how we will display our outputs on the system. We finally got the STM in the mail, so we are starting initial programming to integrate that into the system. All in all, having all of the components is allowing us to move forward quickly with the system.
Emily’s Status Update 10/30/2021
This week I did some more work on the mount. I hadn’t accounted for the cables that hang out of the back/bottom of the microwave sensors, so I used a rotary tool to take some of the plastic away. Since the part that the microwave sensors are secured to is somewhat suspended from the rest of the mount, it is unlikely to cause any problems.
This week I started coding for the LEDs. We will be testing the patterns for communication next week, so I coded the various patterns that we are thinking of using and took video of them. Then I paired those pictures and videos to questions about their effectiveness. I still have to attach photos of the situations that they are meant to communicate for certain questions. The initial questions in the user survey are meant to remove as much of our bias from the view of the participants as possible, while the later questions are targeted as informed feedback.
Albany’s Status Update 30 OCT 2021
After more extensive talks about how to handle memory for the signals code that is being placed on the STM23, I was advised that for integration purposes, that code hosted on the processor should allocate memory directly onto the stack as opposed to using malloc to allocate memory onto the heap, so I am currently in the process of making the necessary changes to make this switch. I am unsure whether the current memory handling structure will be kept as I am looking into possibly simplifying certain aspects of it as initial testing with the microwave sensors seems to suggest that there will be no need for code to cancel out any noise created by the ground. Prior to starting these changes, this week I finished debugging the code for determining velocity (the main issue was that I had used one convention for the positive direction early in the code and then seemed to accidently reverse the convention in determining what to display to the user). I currently have the code returning distance over velocity (i.e. extrapolated time until impact if current velocity maintained). The code is correct for the limited number of cases I was testing on, and after completing the memory switch my next step will be to retest this correctness with a larger number of test cases and with some real-world data that we can now extract from the sensors. The current code is the processing code for a single sensor and I either in the coming week or the one after that depending on what occurs in the next round of correctness testing also need to make sure my teammates and I have a good idea of how to take the results from the two sensors and transfer this information to the LED display. The single sensor processing code already filters to return distance over velocity only for objects of interest. I envision then that this LED code will determine first which object are seen by both sensors and select them to determine display for the center segment (though distance info might also be needed for this to ensure an object two times the distance going twice the speed of another doesn’t appear to be the same) of LEDs, then the lowest distance over velocity for each segment should be used to determine color. We are slightly behind schedule, but we had a couple weeks of padding built in that give us some leeway. Our current adjusted aim is to integrate everything the week after next, so I hope to have the code usable by then.
Jason’s Status Update 10/23/21
For the previous week, I worked on the ethics homework and brainstormed with the team for ethical issues to discuss in class. We also finally saw the majority of the parts arrive in our lab. However, the STM32 was running late, pushing back the start of microcontroller programming a bit.
For the current week, I took a microwave sensor home and hooked it onto an Arduino. From the sample Arduino code given by the manufacturer, I was able to verify that the sensor is working, and that data is flowing from the sensor to the Arduino. I was also able to figure out the communication protocol and the baud rate that the sensor required.
I also modified the Arduino code to output whatever it receives through USB serial, and am working on a Python program to parse and store the data for better visualization. I aim to replicate this Arduino program on the STM32 as a first step to setting up the drivers and the software system.
Albany’s Status Update 23 OCT 2021
This week I did some debugging on the code and ran it through some simple tests. The code compiles and there are no memory leaks according to Valgrind, but after talking with Jason, it seems that how we manage memory might change when we actually move the code onto the board. For now though, this means all the list management and freeing seems to be problem free. Since memory management is going to change, I didn’t run any timing tests, but checked correctness for the distance calculations which seem to working for all the arrays I was running through it. I am having some problems with the speed difference function, I think its arising from trying to filter out objects that enter frame from the front as though it were being passed. I’ve heard Jason has gotten the Arduino and microwave communication up, so I hope to be able to have some data examples soon to be able to move on with the filtering code for ground, or to see if there are any unexpected features of the returned data.
Team Status Update 23 OCT 2021
As a team this week as part of the ethics assignment we put a bit of thought into any ethical issues with our project and got to hear from the rest of the class. The largest problem we found was overreliance on the sensors and accountability if they should fail. We also took some time to measure out the bike we’re mounting the prototype to together and briefly looked over the code.
Last week we finalized purchases for most of our equipment and finally got the sensor in which I believe we should have data back from soon. We also had some discussions about what objects to filter in showing to the rider and how to display different hazard levels, currently landing on colored LEDs.
Emily’s Status Report 10/23/21
Since we’ve gotten in the sensors, I designed the bike mount for the system so we can start gathering data for the filter and do some testing. Using Jason’s bike as reference, the mount screws into the back mounting points and has zip tie points to provide more stability and to accommodate differently sized racks. It has screw holes to mount the STM, the arduino, solder board, and the sensors, and bracketing and zip tie points to house the batteries.
Last week, I worked on the hardware sections and the budget for the design document.
Team Update 10/9/2021
This week, the team worked on the design presentation for the first half of the week, flushing out the details of our design and finalizing parts in the process. We also placed our first firm order for microwave sensors, which should arrive by mid October.
For the latter half of the week, we started progress on building our project, with Emily starting work on the schematics, Albany starting signal processing algorithms, and I starting the embedded code. Hopefully this will save us a lot of valuable time when the parts do arrive.
Jason’s Status Update 10/9/2021
This week I worked with my teammates to refine the design presentation. Since most of our parts have been finalized, I have started building the software foundations for the project. I downloaded the STM32 development environment, set up a project based on the Nucleo board, created a Github repository, and generated code for serial ports using the built-in configurator.
I also conceptualized the code on a high level, and found that our code would be a single task with a period of ~10Hz, the update rate of the sensor. To enforce this periodicity, we will have to find solutions such as RTOS. I also saw possible concerns with our two microwave sensors being out of sync, and am currently discussing with my teammates for a possible mitigation strategy.
Albany’s Status Update 9 OCT 2021
This week I create a brand off the GitHub Jason created for code management to develop the basic code for signals processing. I spent a fair amount of my time this week considering how to implement storage of historical data that might need to be kept for filtering and settled upon a linked list to allow easy ordering step through. For our purposes a list will also work better that a double array as we won’t have to rewrite in the data to shift its relative time position. The list is doubly linked to allow for O(1) removal of old data as I believe time will be more of a concern that storage for us. The list and helper functions have been implemented but not robustly tested yet as I am refamiliarizing myself with C code. I have also have written the code to calculate multiple target distances from the data, my code for this portion is based off the code the manufacturer had provided to preform such a task. I plan to try to have a version of the speed filtering code that will have some changeable constant (concerning what speeds to filter out at what distances/should we show things with negative velocity if they are very close or allow minor negative velocities to account for error) done before class on Monday and plan to get some opinions from my teammates about how to set these constants which I will use as benchmarks about whether or not to display data.