Carnegie Mellon ECE Capstone, Spring 2019 – Michael You, Sid Lathar, Benjamin Huang
The components are coming together for the demo. The demo will probably involve a frontal collision demo with most of the functionality for this aspect included (time-to-impact calculations will activate the buzzers on the jacket). The ultrasound sensors will provide proximity detection.
We finished ordering the rest of the components we need after testing the LIDAR outdoors. The battery seems to be plenty to power the LED matrix with, so that’s a good sign.
In preparation for the demo this upcoming week, I have focused mostly on integrating all the hardware components on the jacket.
One of the major components is the LED matrix, which is large, making it hard to place on the jacket, and has the highest power consumption, requiring careful wire management. We decided that we wanted to put the battery pack on the top of the jacket, so we had to move the LED matrix down a bit on the back.
For putting the LED strips on the jacket, I considered several attaching mechanisms, including:
I went with gluing the strip onto a clothe and then sewing the clothe on the jacket. The reason for this choice is that the pulley joints depended too much on the sewing for the joints, which is risky. Gluing the strip directly on is not flexible, and sewing the strip directly on is not secure, and if we pierce the waterproofing sleeve, then we don’t have waterproofing anymore.
Gluing the LED strip sleeve was no easy task though…the following glues did not work:
You get the idea…it was a struggle. But it turns out there’s a special glue called Silpoxy that works brilliantly, and tada…
I also heat shrinked the LED strip wires for additional waterproofing protection.
I also soldered the vibration motor component of the jacket as well, and will finish the integration before the demo. Next steps are to sew everything onto the jacket, and do a quick Raspberry to Arduino comm test via Bluetooth.
Sid Lathar, A1 | Progress Report #5
Accomplishment:
Last two weeks have been spent debugging the app. The implementation was changed from using google maps API to smart-location-lib (https://github.com/mrmans0n/smart-location-lib)
This change was made because google maps API turned out to be very inflexible to tweak and required a lot of overhead.
Changes to schedule:
The progress is on schedule.
Upcoming work:
Apart from debugging the current implementation of the app, I plan to set aside time for making the UI for the app. I plan to get started on talking with the Pi and concretely describing what control signals we we need for customization of the notification system.
Proximity sensors implemented
Arduino interface with LEDs implemented
Integration in progress
Worked on figuring out programming the LED matrix and figuring out how to integrate the matrix onto the jacket.
In order to reduce memory usage on the Arduino, there had to be some clever tricks used to minimize the representation of the matrix images.
// bit representation of signal image on matrix
left_turn[] = {
0B1000000000000001,
0B0100000000000010,
0B0010000000000100,
0B0001000000001000,
...
}
void show_matrix (uint16_t M[], int r, int g, int b) {
int curr_led = 0;
for (int col = 0; col < WIDTH; col++) {
uint16_t curr_bitvec = M[col];
uint16_t mask = 0B0000000000000001;
for (int row = 0; row < HEIGHT; row++) {
if (curr_bitvec & mask == 1) {
leds[curr_led] = CRGB(r, g, b);
} else {
leds[curr_led] = CRGB(0, 0, 0);
}
curr_led++;
curr_bitvec = curr_bitvec >> 1;
}
// Skip LEDs that loop around at the corners
for (int i = 0; i < NUM_LEDS_SKIP; i++) {
if (curr_led < 300)
leds[curr_led] = CRGB(0, 0, 0);
curr_led++;
}
}
By using a bit-vector instead of a naive integer matrix, we save (SIZE_INT – 1) * 256 = 992 bytes per 16×16 image.
An image from testing the matrix code:
Many possible mounts for the matrix onto the jacket, but the biggest concern is flexibility while maintaining integrity of the matrix to stay on the back. The most likely approach is to glue the matrix onto a clothe, which is then screwed or sewn onto the jacket. Heat shrink wrap and hot glue will serve as waterproofing for holes that have to be put into the jacket.
There is also a preliminary communication protocol that has been developed for the Arduino, which will be utilized when the Raspberry talks to the Arduino via Bluetooth.
Saturday (16th)
Worked on the LKM, but after working a while decided to switch to pigpio instead of using an LKM because measuring pulse width requires two interrupt handlers, one for rising and one for falling edge, or requires checking the pin level within the interrupt handler, which apparently takes a uncertain amount of time. Using pigpio instead polls the GPIOs at a set frequency, while this still isn’t the most accurate, at least the error will be predictable and there is no need to mess with the kernel.
Sunday/Monday (17th/18th)
Worked further on the proximity sensors (ultrasound). Managed to get two working at the same time using my program interfacing with pigpio. Wrote the library to support six, which is the number we need. Am mildly concerned about the performance of the rest of the software running on the pi given the pigpio’s need for polling, but so far it seems like it is okay. Would consider the proximity sensors essentially ready for testing.
Tuesday/Wednesday (19th/20th)
Worked on the bluetooth connectivity between the Pi and the Arduino. Figured out how to configure the HC05 bluetooth module for the Arduino to use. Tested out the C libraries for the Pi’s Bluetooth connectivity.
Updates
Sunday
Monday
Wednesday
Saturday
Accomplishments
Future