The Team
While I programmed the robot, I didn't complete the project on my own. This was my team.
Anirban Muhkerjee
Anirban (Anir) was the ECE specialist on the team. He built circuits that were sure to keep our components at proper voltages. Anir also helped design the gears for our drivetrain.
Prat Sankar
Prat was the mechanical specialist on the team. CAD of the chasis, 3d printing, and making sure the robot didn't fall apart spontaneously were the crucial components Prat added to.
Defining the Problem- Week 6
At the beginning of our 7 week term, we brainstormed the different components of the term and how we wanted to approach them- the type of drive, rough desired speeds, sensors that we would need to identify the different parts of our environment. However, all of these implementations took 6 weeks rather than the planned 4. This means that all programming for this challenge had to happen in under 1 week. This was actually one of the main design constraints as I began writing and testing code- time.
Tools:
-
Sensors to work with:
-
Adafruit BNO055
-
3 Infrared Range finders (1x front, 1x each side)
-
Integrated Encoders on the motors
-
IR Camera to detect the fire
-
Relevant knowledge:
-
Knowledge that there will only be one "fire"
-
Knowledge of where robot starts
-
Challenge to be completed <5 minutes
-
"Address" of fire had to be reported
-
Roadblock placed randomly for extra points (decided to avoid this req.)
-
IMU heading data loops back to 360->0 (to be elaborated on later on this page)
-
Wheels sometimes behave inconsistently
-
Three buildings on the field- only one would have a fire
-
Only 5 days to complete
Challenges:
Field View:
Developing Program Strategy
The key idea of my approach was using simple predefined operation building blocks like driving straight and ninety degree turns to navigate through the streets of buildings. When the IR rangefinders on the side of the robot detected a building, the robot would execute a predefined search pattern depending on the location of the building to find out of this building had a fire. This means the overall strategy moved as follows:
-
Make looping system that updates as fast as possible so sensors can be polled and decisions made when needed
-
Build reliable routine for driving straight for any distance
-
Build turning routine for ninety degree turns
-
Construct state machine so that robot can finish any task to completion rather than time based programming
-
Build up stack of instructions that are executed in order
-
Push the search pattern onto the stack of instructions when a building is detected (includes making the search patterns)
-
Find the fire in 1 of the 3 buildings, drive back to starting block
​
Each of these steps brought their own challenges, but the approach itself appears to have succeeded. Below is a more in depth description of the interesting challenges from the above bullet points.
Challenge 1: Reliable Driving
The problem was fairly simple- my code can only measure from sensors to figure out its current position and adjust from there. Initially, we tried a PID approach from the encoders on the wheels- but this turned out to be inaccurate because of wheel slippage inconsistencies. So even though we tuned the PID to get the encoder counts to match the target pretty well, this didn't actually translate to consistent driving.
​
To summarize- we needed to use the IMU's heading data to perform accurately.
Driving Straight
Driving straight was fixed by measuring the heading of the robot in the 2d plane of the field. When the heading value was too low (over rotation in the counterclockwise direction) the left side would slow down until the desired value was restored. This was complicated around the 0-> 360 degree changeover on the sensor, but a couple of if statements fixed this.
Turning Consistently
Turning was also solved with the IMU. This time, there were many corner cases to consider, as over turns could result in crossing over the 0->360 threshold. Also, the handling for resetting the target heading was done here. Resetting here means if the target was 360 and the robot needed to turn right, it would change the target to 90 to keep consistency between readings and targets.