Author: jiachenx

Since Thanksgiving, I have been working hard to engineer a GPIO-based solution to transmit LED codes as required in the design, in order to circumvent the problems we had with serial communication. That has since been finished and tested. Although there are some problems working with the full set of LED control routines on the Arduino, a reduced set works and the oscilloscope measurements from the STM look normal, so we’ll have to look on the Arduino further to solve this problem.

I also helped with the assembly of the system, soldering and heat-shrinking some wires from the STM to the Arduino and sensors. The assembly was completed and I managed to load a version of code into the system that controls the front LED lights accurately reflecting sensor readings and signal processing results. This marks the completion of the duties that were assigned to me, so I can now dedicate my time to help with testing and debugging as part of the final step of the project.

This week, I worked on integrating the code from Albany into the STM32 library, and trying to interface with Emily’s LED code by sending LED codes to the LED arduino.

Code integration worked well, as the requirements were communicated well and ahead of time, and Albany left a clean interface to device memory for me to implement. However, interfacing with the Arduino proved much more difficult than usual. My initial idea was to use I2C, but through hours of debugging, including trying different pull-up resistor resistances and using the oscilloscope to debug, I still haven’t been able to get it working. SPI also fails to display any message on the oscilloscope.

My next plan is to work with Emily to interface directly with the STM32 registers without the hardware abstraction library (HAL) that some say is problematic, and if that fails I will fall back onto the inelegant but effective solution of using 6 separate digital pins to output the LED codes directly through GPIO. Before this is done, however, I am able to get the LED codes to output through USB serial, so debugging and optimizing Albany’s code can continue.

This week before class time, our team prepared for the interrim demo by finalizing the work we’ve done separately and present them in a working form. This includes the LED circuitry worked on by Emily, the data collection and signal processing by Albany, and the software interface with sensors by Jason. Overall the demo went well, with no major problems.

After the demo, Emily and Albany went to Schenley park to take some measurements with the sensor as part of the next round of testing, with the goal of getting more detailed data. The results showed us that the specs given by the manufacturer of the microwave sensor were not correct, as we were only able to get about 10m of usable range, which we will investigate this week.

Progress has also been made to the power circuitry, enabling the lights and the microprocessors to be run off battery, and the software, fixing a problem with data alignment and enabling the I2C master bus to communicate with the LEDs. We will work to start integrating the components next week, and iron out any bugs that appear in the process.

This week, we successfully demoed the components of our project separately as part of the interim demo. To prepare for this, I expanded the STM32 code to read both microwave sensors through separate UART busses, adding alignment to data headers so that the sensor data would be in the correct locations of the buffer.

Unfortunately some problems arose during the demo, in which the Python program printing out data received by the STM32 was coalesced, and was shorter than what was expected. I investigated this error through the STM32 debugger and concluded that the problem stemmed from the timing of the Python program itself, since the internal data arrays were all aligned correctly without problem.

I also did some basic profiling and benchmarking to assess the feasibility of the STM32 that we chose, and concluded that the UART reads, although slower than what we expect, exceeds our user requirement for 250ms update time (4Hz). I also found out that the time difference between two reads is negligible for our use case, and that one spectral data array occupies less than 1% of the device memory. According to Albany’s code, I have verified that the STM32 is indeed capable of running our workload well.

In the next week, I plan to start integrating the code from Emily and Albany. First I plan to write a test program to control the LEDs using the 7-bit LED codes that we agreed on, and then a ring buffer for storing data necessary for Albany’s signals code. After that, I will integrate that with the signal processing routine that Albany has written and start testing.

This week, I focused on getting the sensors to work with the STM. So far, I have initialized both of the microwave sensors and written interrupt handlers to write data into a shared buffer. I have also  verified that it is working by reading from the STM from the Python terminal. Finally, on the STM, I initialized the I2C ports to communicate with the LED controller in the future. For the demo, I will be preparing a demo with Python to showcase the reading of microwave sensors on the STM, after which we are ready to start integrating. I also taught Albany how to use my Python code to read the microwave sensor on an Arduino, which she will be using to test the sensors on the weekend.

I have run into an issue by discovering that neither the Arduino nor the STM32 has an accelerometer, which Albany will need for signals code, but thankfully I had one on hand from Build18 last year. It provides 9 degrees of freedom, which is much more than we need. I will start integrating it next week, while providing Albany with the format of data it provides.

This week, I kept working on the Arduino to test communication with the sensor. Through some debugging of my Python client, I was able to fix the issues mentioned in last week’s status report and start streaming data to the computer in the correct format.

This enabled us to do some testing with one of the sensors, from which we observed that although the distance data may not be correct, the spectral lines seem to be outputting reasonable values from which we are able to determine the distance.

I also wrote some code to store the spectral data arrays into a .csv file for further analysis, although we did not yet get data of actual scenarios. That is planned for next week, when Emily’s bike mount will be completed.

My plans for next week also include streaming the sensor data to the computer using the STM32 to verify the device drivers, and extending the Arduino’s code to support dual sensors, so that we can test interference between sensors. If more time is present, I will also enable the built-in accelerometer on the STM32, and start writing the drivers to control LEDs.

 

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.

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.

 

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.

 

This week, my teammates and I were able to mostly finalize the parts that we will be using for our project. I proposed the use of a microwave sensor to the team, and after discussions and research about its abilities and pros and cons, we decided to switch our design to an array of 2 microwave sensors. To potentially reduce code complexity, we also added an Arduino to our system in order to drive the LEDs using manufacturer drivers, since those are readily available for Arduino.

The progress in deciding parts has enabled me to confirm that the STM32 development board we initially picked out has enough ports to read inputs on both microwave sensors and control the Arduino LED driver, and enough capability to process the required data.

I had discussions with Albany, who is currently working on signal processing code, about the potential need to store many scans from the sensor to accurately filter out the ground, which  might be present in our microwave sensor readings. We concluded that it will not be of an immediate concern, since we have 512KB of memory to work with, while each data array from both microwave sensors is only 252 bytes long. We also decided on using C to develop the algorithm, with more complex processing written in Matlab and generated into C code.