Ogrebot was my robot for the Trinity International Robot Contest 2018. For Trinity, the goal of the robot is to navigate a maze, find, and then extinguish a candle. Here is the link to the rules. The hardware was done exclusively by myself, and the software was done by cvxluo, Lachlan, and Stephane.
I started designing this robot in May 2017 for a competition in April 2018. You may say this was excessive, but you will see later that it may not have been. During the end of the school year in 2017 (march - june), I probably changed the CAD program I used at least half a dozen times, but this robot got started when I was using Fusion 360, which I still highly recommend, it's just not my favorite (SOLIDWORKS master race). When designing this, I wanted to spend a large amount of time making sure I had EVERYTHING planned out so we wouldn't run into an issues (at least hardware related) down the road, which proved to work very well.
I knew I wanted the robot to be modular, easy to repair, compact, have an accurate, relatively powerful drive system, and have all the sensors necessary to make the software as easy as possible.
To do this, I decided on a design with circular plates connected with standoffs, and as we were supposed to get a laser cutter, all the plates would be laser cut.
I was happy with the motors we used in the previous years robot, Boxbot, so I decided to reuse them. They were the Pololu 100:1 gearmotors that had built in quadtrature encoders. This allowed the motors to have very high torque, but also rather quick (Faster than we ever could need), but also the quadrature encoders would give us accurate positioning of the wheels down to 0.05510485229 degrees, which again would be more than we could ever need.
For the wheels, I initially wanted to some cool omnidirectional shit, but then I decided not to overcomplicate stuff for the~~ code monkeys~~ software developers. So as I wanted to use one of Pololu's aluminum motor mounting hub to attach the wheels to the motors, it was a pretty easy decision to go with Pololus 90x100 wheels. These wheels are nothing special, but are very solid and worked great for our task at hand.
Finally, as balancing on two wheels is rather difficult, I needed a caster to support the weight. Boxbot used a pretty shitty caster, which stopped spinning within weeks, so I decided to get a nicer caster. This caster was slightly larger, but I thought it would spin nicer (which it did), so I went with it. It did end up picking up a lot of dirt making it spin worse, but it still ended up being better than anything I had used before.
Here's a picture of the drive system.
I also added a cutout for wiring any sensors to the bottom of the robot, as I planned on putting a color sensor on the bottom to detect the change of rooms in the maze.
This is not the best drive system I have designed, but I was definitely satisfied with it, and it was pretty solid.
Deciding on the sensors was one of the most difficult parts of this design, as it was one of the most important, and I did not want to fuck it up. I decided on using ultrasonic distance sensors for positioning. As I wanted 8 of them (Front, Back, Left, Right, and at 45 degrees), I decided to go with the HC-SR04 from sparkfun. I chose ultrasonic over alternatives such as infrared as they were more accurate, cheaper, and could be read easily by the Raspberry Pi. The issue, which I did not find out until the competition, was that the sensors at 45 degrees returned inaccurate readings due to the nature of sound bouncing away.
For addition sensory, I added a BNO055, which had a 3 axis magnetometer, 3 axis accelerometer, and a 3 axis gyroscope. This was meant to be used for accurate turning and such.
Finally, the competition has white lines on the floor to be the difference between the hallway and the rooms, so I added a color sensor to the bottom of the robot.
Here's a picture of my main sensor layer:
I also had 2 perma-proto boards which were used for the signal distribution.
The goal of the robot is to extinguish a candle, so the extinguishing system was very important. To detect the candle, I used a flame sensor that was basically just an IR LED, which we used the year before with Boxbot, and worked well. Actually extinguishing the candle was a challenge, but I had a pretty good system from the year before, so I stuck with that. I used an 8g co2 puncture device from Leland Ltd, attached via a 1/4" to 1/8" NPT pipe nipple to a versa valve, provided by the contest, which allowed us to easily control the output of the co2.
Finally we needed to control everything, so we decided to go with a Raspberry Pi 3, which should have enough computational power to run everything. As I was doing all the wiring on the perma-proto boards on the 2nd layer, and the pi was on the 3rd layer, I decided to use an IDE cable with a Pi Cobbler, to transfer all the wiring down neatly.
Here is a picture of the control layer, I did not model the versa valve but the empty space next to the pi was where I put it.
For the power system, I used a 3s 2200 mAh battery for the motors, and a 2s 2200 mAh battery for everything else, which was attached to a UBEC to step down the voltage from 7.2 v to 5v.
Construction on this robot was very easy as I had already planned everything out. Sadly the laser cutter did not come in time, so I ended up having to 3D Print all the layers. Another thing I realized later is that the ultrasonic sensors output a 5v signal, whereas the pi can only read 3v3, so I added a simple voltage divider to the sensors.
Here's most of the wiring diagram, it does not have the voltage dividers and the encoders are plugged into 5v instead of 3v3, but everything else is accurate.
This is where everything went to shit.
This competition was supposed to be the one where everything worked. I had started the project a year before. I had completely finished the hardware by early November. Yet, it managed to be one of the worst competitions I have ever been to. This was because all the issues we ran into were software related. This caused me extreme stress as there was nothing I could do about it as I'm not a software guy. We ran into many issues including the following:
- Having weird ultrasonic readings because of weird threading issues
- Having to make an encoder daemon because it required readings all the time
- PIDs getting messed up causes hard to diagnose issues
- Having weird issues with ultrasonics at anagles
Having threading issues
What I/we learned:
WORK ON SOFTWARE AHEAD OF TIME!!!!!!!!
Do not use ultrasonic sensors at angles
- Fully designing the robot in CAD was very useful
- Versa valve works great
- Pololu motors are nice
- Encoders should have a dedicated signal processor
- encoders are useful
- PIDS are great except when they dont work
- The BNO055 was not particularly accurate
- Have everything working before the competition
- Test all sensors before hand