This week, I worked on soldering our circuit parts together, along with integrating sensor data reading over TCP communication to a local web server on the ESP8266. I have encountered multiple issues which have set me back in my progress toward software and hardware integration. When editing the code with hardware integration, we found stability issues which left no memory for local variables to issue commands to the ESP8266 module to receive and send data. This led to a pivot in my coding to try and make the sensor sampling, collection, and retrieval possible with a python script with just the ENS160 sensor. The differences between using the Wi-Fi module over the NodeMCU are leading to a lot of debugging issues. due to the lack of libraries around the ESP chip, I have realized through research that sending a JSON string across is going to take manual entering of response codes and header metadata sent across in normal TCP/IP communication for it to be read by a requests library on Python. Trying to integrate the existing NodeMCU library with the Wi-Fi module proved unsuccessful, and I am currently working on trying to code a function with the needed metadata and information that can then be read by a script to run our classification models successfully. With the Arduino Mega, I imagine this will be an easier decision, so in the next week (and in the next 2 days, hopefully), I need to determine whether the early issues I faced with this pin, combined with the ones I’m facing today, are enough to consider an alternative. The lack of hardware and software drivers with this chip is making software and hardware integration harder than it needs to be, in my opinion, but I do want to make an as informed decision as I can about this.
Team Status Report for 3/25
This week, we worked on robot construction and integration of our sensor and motion subsystems. In terms of robot assembly, we began soldering connections onto a new protoboard and organizing all of the internal connections. We also glued the robot frame together and were finally successful in securing the motors to the chassis using wood glue. This greatly improved the stability of the wheels and increased the accuracy of the robot’s motion. In terms of integration, we finally wired together all of our subsystems so that our sensors and motors are connected and controlled by the same MCU. When we combined all of our systems together, we realized that the 9V battery was not enough to power every component. Therefore, we connected an additional 9V battery to directly power the Arduino. We also worked on software integration, which involved combining the motion logic and sensor logic. We were able to successfully take sensor readings at a specified sampling frequency while also issuing motor commands. We also added random path planning to determine the course of the robot instead of using predetermined coordinates.
However, we also identified several issues while integrating our subsystems. The biggest issue is that our sketch takes up too much space which causes stability issues to occur and does not leave enough memory available for local variables. Because of this, we are unable to establish the wireless connection required to send the sensor data to a local machine. Due to this, we will need to upgrade to an Arduino Mega so that we have more flash memory. Till we receive the new parts, we will not be able to continue with our system integration which might set us back by a few days.
The wi-fi subsystem is also presenting multiple issues with setting TCP/IP connection protocols with our web server because of the stability and memory issues. In general, the chip sends raw data strings, so the program needs to account for a response status, and user header metadata in order to be perceived as a proper response for the machine learning model to retrieve it. Doing this across several sensors with multiple data streams is a big risk to mitigate for the team moving forward. Working on integrating these systems, as described above, is going to set us back a few days.
Moving forwards, we will need to define our expectations for the interim demo and work on refining individual subsystems.
Caroline’s Status Report for 3/25
This week, I worked more on robot assembly and assisting with the integration of our different subsystems. I glued the components of the robot together and the motors are finally secure which has improved the accuracy of the robots movement. While working on integration of the sensor and motion systems, I helped test and debug when we ran into problems. We ran a few informal tests with the ENS160 sensor by thresholding the ethanol reading and were successful in getting the robot to stop when alcohol was placed around 6 inches away from the sensor. Initially, our goal with integration was to see if we could let the robot run while sampling and collecting data, but we ran into unexpected issues due to Arduino hardware constraints. Our program was too memory intensive to run on the Arduino, so we were unable to transmit the sensor data wirelessly. I ordered an Arduino Mega and another Grove shield and we will have to replace our old Arduino Uno as soon as the part arrives. In the meantime, we can still collect data through a wired connection, but our priority is more focused on integration and preparing for the interim demo. Potentially we will use a more simple thresholding method for scent detection instead of a classification algorithm for our interim demo, so robust dataset collection is not the number one priority at this stage. We will need to define as soon as possible what we aim to accomplish before the demo and form our plan for next week accordingly.
Aditti’s Status Report for 3/25
This week I worked on random exploration code for the robot and integrated the sensor reading logic with the motion code. The code is now set up to have two state machines that update and sample at different frequencies without interfering with each other’s timing and logic. The sensor updates take place at a frequency of 10Hz while the encoder updates take place every 50ms. The robot now randomly computes a coordinate within 15cm of the current position and travels to it until it detects a TVOC reading above a certain threshold, after which it stops. The robot resumes traversing the map randomly once the readings fall below the threshold. During this process, I identified several issues. First, there was a bizarre issue with our encoders – every now and then, the count increment on the encoder would jump from a simple double-digit value to a value in the thousands which should never occur. We identified and ruled out several potential causes for this – issues with update logic, integer overflows, etc. We still don’t know the exact cause, but it is likely due to hardware issues, and we have a band-aid fix to stop the motors and ignore the previous iteration in case this happens. We lose 50ms worth of data, but it seems to work. Another major issue is that our program with wi-fi communication takes up too much space to run smoothly due to memory usage issues. We will need to switch to an Arduino Mega with the Grove shield for the same to have enough memory. Another issue is that our robot seems to struggle with rotations every now and then on the boards that we got, but seems to work well on smoother surfaces. We are looking into more ball casters that may potentially help with this. Due to these setbacks, I will be slightly behind on schedule but once we have the new parts it should help get us back on track. Next week, I will prepare for the Interim Demo and continue to work on navigation towards a scent source.
Eshita’s status report for 3/18
This week I worked on establishing a data collection pipeline for the sensors. The updated code now stores values and prints them in a CSV format, which will then be read by a python script from serial communication. This way, we can collect data efficiently and in a quicker manner. An example of the columns we tried collecting data with is shown below. 
A major problem we faced was trying to work simultaneously on the motor calibration and odometry of the robot, while also wanting to collect data from within the car to emulate the readings the sensors will be getting. Hence, while Aditti and Caroline focused more on the odometry, I set up a pipeline that would be easy to distribute work within the team. We were also facing problems with the hardware drivers for our particular wi-fi module with Azure as discussed in our weekly meeting, so I am also working on code that will send across the JSON response to a python script that can run a classification model.
Caroline’s Status Report for 3/18
This week, I tested a new method with glue to secure the motors to the robot. This method worked decently during our initial testing, but came undone with more usage. As a more permanent solution, I am looking at some options for tube or u-shaped brackets and will place an order this weekend. I also helped out with testing the motor control code that Aditti set up this week. We ran simple unit tests which would instruct the robot to navigate to a simple series of points such as (0, 0) -> (0, 1) -> (1, 1). Due to slight differences in the motors or other external factors, the robot is not always able to reach the target points. I wrote some additional code that helps the robot correct it’s course if it strays too far off of the intended path. I will continue helping to test the robot motion next week. Dataset generation is also my priority for next week. Now that we have the data pipeline set up and all of the necessary materials, I will start on this as soon as possible.
Team Status Report for 3/18
This week we focused on motor control and data communication between the sensors and the local machine. While working on the code to fine-tune the rotation and translation motion of the robot, we identified several problems and potential risks. Firstly, the error from odometry and encoder readings seems to accumulate very quickly which sometimes causes the robot to overshoot and not converge to the target position. To account for this, we are planning to reset the encoder readings periodically once the robot reaches a predetermined target coordinate on the global map. Additionally, we added a self-correction mechanism in case of overshoot. Another issue is that most of our monitoring and evaluation of the robot coordinates and encoder readings happens through the serial port, which requires a tethered connection that affects the robot’s motion. We’ve also identified an issue in the hardware – our design would require the motors to be more secure than what we have currently, as compensating for hardware limitations in the codebase is not enough.
We decided to move away from using the cloud and instead process the sensor data on a local server instead. This is primarily due to the incompatibility of our wifi chip with the Azure cloud. In our experiments, we realized that accessing data on the localhost does not incur too many additional costs.
This week we also set up the pipeline for recording sensor data through serial communication to a CSV. We also acquired 99% ethyl alcohol and spray bottles. Now, we have all of the setup that we need to start dataset generation and we will start collecting data as soon as possible. At the minimum we need to get baseline readings for one scent, such as alcohol, so that we can start testing out the robot’s ability to actually track down a scent.
Aditti’s Status Report for 3/18
This week I worked on motor tests for the robot. I worked on getting the robot to travel a fixed distance straight ahead, as well as rotate to a specific angle. I was able to get the robot to travel to within 2cm of the required coordinate and within 3 degrees of the required angle repeatedly. I then tested out the robot motion for a series of target coordinates to see how the error accumulates. During this process, I realized that the speeds for translation and rotation need to be tuned independently to ensure that there is no overshoot in either of them. A higher rotation speed and a lower translation speed were required. I also noticed that mid-range PWM signals were not enough to be able to generate enough power for the robot to move, which makes it difficult to implement PID control as the actual robot speed does not scale proportionally with the PWM signal. After tuning error margins, I was able to get the robot to automatically compute rotation angles from a series of coordinate inputs and follow them, however, the accumulated error is too high by the end of the 4th coordinate that the robot cannot converge to the target position. Having a tethered connection while testing to monitor the coordinates also skews the robot’s performance due to the additional forces on the robot. The robot is also completely unable to move on rough and textured surfaces such as carpet floors. I will continue to work on this for the next week and make the coordinate generation code randomized.
Eshita’s Status Report for 3/11
This week, I worked on creating the code for the Arduino and sensor array to transfer data from the sensors to the Arduino. The code is attached on Github here (https://github.com/aditti-ramsisaria/ece-capstone) in sensors/ and ens160_lib/. I faced a number of issues in implementing all the sensors to work together. The ENS160 library was not updated with the most recent libraries so I had to update one of the functions in the Arduino library made by ScioSense to make it functional. The picture of the sensors working is attached below.
The other aspect I was working on was communication using the ESP8266 chip. There is a way to send JSON data across wifi to a local web server hosted on the Wi-Fi module. The working implementation of this is attached, showing a simple JSON message hosted entirely locally on the Wifi-module. Sending across data using JSON is very feasible, but adds complexity in retrieving the data from the web server for the classification algorithm. On the other hand, the ESP8266 chip we have ordered does not have enough documentation for being implemented on Azure with MQTT, as was highlighted in my previous status report. We have a NodeMCU which works with Azure, and I will research communication between the NodeMCU and the Arduino since our sensors will only work all together with I2C on the Arduino.
Caroline’s Status Report for 3/11
Last week, I worked on testing the motors when assembled in the robot chassis. After installing new fasteners for the motors, the range of motion of motors was reduced and the wheels were able to support the robots weight. However, there was still wiggle room which allowed the wheels to become a bit unstable. Because of this, the robot moved somewhat unpredictably when directed to move in a straight line. When testing, the robot often curved slightly to the left which we hypothesize is due to a small, expected miscallibration of the motors as well. Next week, I will try securing the motors with a stronger fastener and test the motion again to determine if further tuning is necessary. I will also help work on the sensor system assembly. One key concern we have is how sensitive the sensors will be when installed inside our robot, and determining the maximum distance at which scents can be detected with our testing setup. After more experimentation with the sensor sensitivity next week, I will determine if any modifications need to be made to the robot to help increase the range at which scents can be detected.