Posted on

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.

Posted on

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. 

Posted on

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.

Posted on

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.

Posted on

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. 

Posted on

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.

Posted on

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.

Posted on

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. 

Posted on

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.

Posted on

Aditti’s Status Report for 2/25

This week I worked on assembling the robot and motor control. Caroline and I worked on laser cutting all the pieces of the robot chassis which took a few iterations. The first iteration of the top piece was cut on 6mm wood which proved to be too thick for achieving the bending effect we were going for. We recut the top piece on 3mm wood and adjusted the other pieces accordingly. We also realized our ball caster is too big, causing our robot to tilt backward, so we’ll have to get a new one of the appropriate size. I worked on interfacing the L298N with the DC motors and controlling them through the Arduino. I initially struggled with getting the encoders to read correctly using hardware interrupts but eventually figured out the timing and update rules. I also implemented PID control for position control for one motor and will work on extending this to the robot position next week. We still need to test the current code with the motors mounted on the robot to ensure that we can achieve straight-line motion, which I plan to do next week. Additionally, I worked on preparing for the design review presentation and planned out connections and interfaces for the design report. 

Next week I will continue to work on motor control and odometry and plan to get the logic working for random exploration on the field. My progress is currently on track with the schedule. I will also be working on the design report over the next few days. 

The updated test code and CAD files can be found on the github repository: https://github.com/aditti-ramsisaria/ece-capstone