Pallavi – This week was mostly spent working on the design presentation and design document with Arushi and Shreyas. From delving more into the design specifics, I started looking into more details of how we’re going to use the ultrasonic sensors. As a team, we were going back and forth about what exactly we wanted to send from the sensors to our path planning algorithm. Our first idea was to only send a 1 or 0 corresponding to whether or not an obstruction is there for a given sensor. However, if we want to support the design specification of not only being able to sense obstructions but also move around them and fix the path, we would want more information about the obstruction. In order to do this, we would need to come up with a serial protocol to encode this data, since we would want to know both the sensor’s value and also which sensor is associated with which value. Shreyas and I discussed how exactly we want to encode the data being sent to the Pi. Our idea is to use one byte for each sensor. We plan to use 3 MSB to ID the sensor since we have 6 sensors total, and the remaining 5 bits to encode the data. Because we don’t need to have specifics about the exact number of cm distance from the obstruction and rather a range, we can figure out a scaling from the sensor value to the actual value we send.
Next week, I want to focus on figuring out the exact encoding of data. I also want to start setting up the physical cart and looking into how to use the on-board iRoomba sensors.
Arushi – This week I worked on the design presentation and doc. To do so, first I made sure to further think through the overall design and how my module of the image processing fits into it. Specifically, after hearing concerns of our path planning and turning algorithm, I looked more into it. We plan to characterize our algorithm to address two types of turns. Wide turns in areas such as a human moving to another side of an aisle and sharp turns such as a human walking out of an aisle and turning a corner. To address the first type of turn, a wider one, we plan to have two circles on the fronts and back of the target human. Our algorithm will draw a minimally enclosed circle regardless of if the entire circle is seen. This way the further back circle will be smaller and we will able to tell which way the human turned. When only one or no circles is seen is indicative that the human has been lost or made a sharp turn out of the aisle. In this case, we will have the robot make a full turn and stop when a circle is seen. We focused on this, for this week although this will not come into play until after the midpoint demo. Thus, for the next week we want to work more on building the cart and have the separate modules interact with each other.
Another aspect I thought through for future milestones is when the human detection tells the cart to go straight but the obstacle detection doesn’t allow it to do so (let’s say a child gets in between). In this case what I proposed is that we check the closest sensors to the desired direction and move our robot in the direction of the sensor that shows it is further from an obstacle. Then we do this check again as to where the human is and if the sensor in that direction allows the cart to move in that direction safely without hitting the obstacle.
Shreyas – This week was mostly spent preparing the design presentation and the design document as well as figuring out how to integrate the major subsystems. I created a more elaborate system architecture block diagram that includes the hardware, software, and interfaces between the subsystems. I also looked into the benefits of having a dedicated Arduino to handle polling the ultrasonic sensors over having the Raspberry Pi handle it directly. Having the Arduino handle it will prevent wasting CPU time on the Raspberry Pi that can be used for the image processing algorithms. The GPIO pins on the Raspberry Pi also support interrupt driven handling. We can use this to our advantage by having the Robot Control Module only handle obstacles when a interrupt handler gets fired.
I also confirmed the power supply we would be using for the Raspberry Pi. We are going to buy Miuzei Raspberry Pi 3b+ battery pack. This is an expansion board that also provides a casing so it’s more robust. We can use this board to also power the Arduino.
All of us – in general this week we worked on further defining how the separate components will interact with each other, which is further talked about in depth above.