This week was spent primarily working out bugs with porting the code to the ATSAMD21 processor that the Trinket M0 uses. In addition, we ran into more problems with lack of I/O, which was solved with using all of the available data lines on the …
This week was about beginning integrating and improving the clutter detection code. 1) Establishing the Protocol between Server and Client Note: Client = RPI Zero W / Camera ; Server = Hub Jeffrey and I sat down and established how the server and client would …
This time around, finally got the new hardware in. I spent this week soldering debug ports on the new hardware. Unfortunately, I ripped one of the debug pads off the board so… one of the boards is unprogrammable… but the other one works fine. I’m still in the process of porting the code, especially since the process of clock switching is more complicated than with the STM. I also had to make major changes to my toolchain, as memory mappings were different and I needed to configure my debugger to a completely different device with different linking scripts, speeds, and configurations.
On the embedded side, there were major setbacks, mainly due to completely rendering one of our new boards unusable (thank soldering). There were also major toolchain changes needed in order to support two active branches of development between the wearable and the button, both of …
We had to present a demo this coming week, so I got my protocol working, and wrote down code to display for the demo. 1) Sending Images from Client to Server The biggest issue I had this week was being able to send the image …
This week I did more research into our trilateration method and how we were going to get it to work. After writing up ways of how our trilateration would work, I realized a major flaw in our design. The trilateration design that people have implemented in papers depend on having stable known wireless access points to read from. Within a house there are stable wireless access points to read from but the distance to them is unknown and would require an enormous amount of setup time to find those values out. So, with that in mind, I managed to quickly find another approach to find out location that would suit our needs. For our device, we really just want to know if a person is within some region. So I planned out a technique that uses two wireless access points between a region we want to check if a person enters. This happens to be our hub and our camera. If the wearable device sends its location to the hub and its distances from both the camera and hub are within some threshold, we can determine that the person had entered that defined region attributing any mess caused to them.
This week I wrote a wifi scan program for the hub to survey the area for wireless access points, so we can use those rssi values for our trilateration calculations. I also added a task scheduler to the main hub program. To save the task …
This week, we made major headway on the hub and embedded fronts. We were able to connect the button to the hub and mimic the wearable to send location scan data, which the hub was able to parse. On a separate note, we were also …
This week, I spent a lot of time at the site of testing our device(my teammates’ house), and managed to accomplish a bunch of things regarding the actual protocol of the image transfer.
1) Capturing Image over a sequence of time and preprocessing
This base code was written and tested. It takes an image of the clutter zone, at an interval of every 5 minutes. This interval can be changed according to preference. And then, it crops the image so that only the zones we care about sent to the hub for processing.
2) Disconnecting the RPi Zero W from the internet, and connecting it to the Hub’s wifi network
For this step, I removed the SD card from the RPiZeroW and rewrote the WPA supplicant. It took about three tries for me to get the supplicant right.
2) Sending Image to the Hub
This part took a while. Initially, I was unable to connect with the server that was written by my teammate on the hub. Took us a while to figure it out, but what was happening was that our hub’s IP address was 10.0.0.0, so the RPi would refuse to connect to it as, the IP address ended with ‘0.0.0’ Once a connection was established, initially I tested sending string messages to an echo server my teammate wrote and managed to connect to it. After that, I started writing my own server and client to send and receive images, and send ACKs to the Camera. I am currently able to send the cropped image, but sending the full image corrupts it, and I am looking into that.
3) Functions for Image manipulation
Since image manipulation is going to be integrated into the Hub. I have been writing functions from the code I already had, so that Jeffrey can just call them at the right places, and doesn’t have to do much.
Besides that, I worked on the ethics assignment. The readings were surely very interesting. I had a fun time reading them.
This coming week, David and I will be looking into getting the exact position of the object on the counter and associating it with the user.
This week was pretty hectic. After realizing the the GEMMA M0 lacked sufficient I/O ports to adequately control the breakout board, we were in a frantic rush to replace it with new hardware. We settled on the Trinket M0, which offers more I/O. We almost ran …