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.
Team Status Report for 3/11
This week we worked on receiving data from the sensor array with all the sensors connected to the Arduino. We can now receive readings on levels of CO2, TVoCs, temperature, humidity and CO, NO2 all together while connected on the Arduino. We also defined our communication protocol using JSON payloads to send it from the Arduino to the cloud using the ESP8266 Wi-Fi module. We tested sending a JSON message across the chip to a local web server and were successful, and would like to continue testing this method.
From preliminary testing on our sensors, we find that the ENS160 is a much stronger sensor than the Grove multichannel sensor. It is also sensitive to the carbon dioxide being exhaled due to breathing, so our data collection will have to account for the above. We tested our sensors with an isopropyl alcohol wipe and found that it can detect a rising change in gaseous distribution when objects are moved close to the sensors. We found that using a fan increased the distance at which an object can be detected by the sensors. For our next stage of testing, we will place the sensors inside the robot and determine the distance at which scents can be detected inside the close chamber with the fan running.
This week, we also finally tested out the motion of the robot with the new motor holders. Even though the holders made the motors more secure, it still allowed some movement of the motor axles which caused the robot to turn slightly when instructed to move in a straight line or move a bit unpredictably. We will look into additional attachment methods such as glue or screws to better secure the motors. After this, we can focus more on tuning the motor control code.
We also worked on the Design Report and incorporated feedback from our Design Review presentation to include more stringent design requirements and define our communication protocols across all the subsystems. While working on the report, we defined our subsystems on the basis of our robot planner, control, design and the communication of how sensor data will travel from our robot to our classification system.
Aditti’s Status Report for 3/11
For the last week, I worked on getting the motors mounted on the robot and getting the robot to drive a fixed distance in a straight line. Currently, we are interrupting on a hardware interrupt pin and reading from a digital pin for the hall sensor readings for each motor, and using these to update the encoder ticks. Then, the distance travelled by the left and right wheels is computed using the gear ratios and robot geometry in cm, and the robot continues forward till it reaches the target distance without PID position or speed control. From initial testing, we found that our wheels and motors were not secure enough to ensure repeatable motion from the robot, although the traversed arc length was always within 2-4cm of the target distance. We tried to secure the motors better using laser-cut brackets to hold them in place. This helped, but we will still need a better way to secure them in place. For this we will be gluing down the motors/screw them in so that there is no shakiness. Once this is done, we will assess if there is a need to implement PID control or if the robot’s performance is good enough for our purposes. I also helped out with getting the sensors set up for reading and calibration, and spent a considerable amount of time working on the report last week. Next week, I will be focusing on securing the motors, working on the tuning code, and implementing PID control if needed.
Caroline’s Weekly Status Report 2/25
This week I worked on the design and assembly of the robot chassis and hardware. I made multiple adjustments to the CAD model in order to better accommodate our parts. First, the top piece of the chassis was too thick and inflexible to mold into the desired form factor, so I made adjustments to the front, back, and side plates to accommodate a thinner top panel. Additionally, I measured the dimensions of our motors and added supports to hold the motors and holes in the side panels to fix the axel. When testing out these supports, we found that the motors were not secure enough, so I drafted a new CAD design which ensures that the motors will not be able to move in any direction during operation. I will be laser cutting and testing this design as early as possible so that we can proceed with testing the calibration of the motors in the robot. I am currently behind on the sensor system assembly as one of our sensors has not arrived yet, but I will start working with our current sensors next week and help with the interfacing of these sensors.