This project requires teams of students to design and build a robot capable of autonomously navigating an arena. The robot must also locate target weights, pick them up and bring them back to 'home base' to score points.
The robot was constructed from a mix of existing metal components and custom 3d printed parts.
The intake mechanism consisted of 2 inwards spinning wheels. These were mounted on pivoting arms and pulled inwards with rubber bands. This allowed the wheels to tightly grip the targets and draw them in even if slightly misaligned. The weights are then drawn onto a conveyor belt system which drags them upwards into the storage area.
The storage area fills the inside of the robot and consists of a large acrylic plate. A gate at the rear prevents the weights from rolling out the back. However, this gate is mounted on a servo and can be opened, allowing the weights to be deposited at home base.
The robot uses a tank style drive system with one tread on each side. A 3d printed pulley links the tread to a high torque DC motor. An additional system of smooth pulleys provides adjustable tension on the treads. The treads can be driven forwards and backwards. The DC motors do have built in encoders, but the tank style drive system makes this highly unreliable for position tracking. This is because unlike a wheeled system, the treads are constantly slipping whenever the robot turns. As a result, it moves around unpredictably and position is lost. This is especially true if the motors spin at slightly different speeds.
To combat this position inaccuracy, a separate odometry system was developed. This consists of 2 perpendicular trackers, one for the forwards direction and one for the sideways direction. Each tracker consists of a hinged wheel & bearing that can move up and down over obstacles, while remaining in contact with the floor. The wheel axle contains a small magnet which is read by a magnetic encoder fixed to the housing. The robot,s position in the arena can be tracked by measuring distance travelled by each odometry wheel and accounting for their relative offsets. It ended up being fairly accurate but does start to accumulate slight drift over time by the end of the 2 min round. Our solution was just to perform most actions early in the round while it was still accurate.
The robot uses ToF sensors to detect and lock on to target weights. The sensor assembly consists of a pair of sensors mounted on a bracket, one up high and one down low. This allows the robot to distinguish between target weights and arena walls. The whole assembly is mounted to a servo motor, and it can scan side to side to build a full map. There are 2 of these sensor scanner assemblies, one on each side at the front of the robot.
A full CAD model was created in Onshape. This includes all custom 3d printed parts. The model includes most of the given mechanical parts as well. The model can be viewed here (account required). Note the folder structure is still quite a mess, I haven't got around to cleaning it up, and parts are still hidden in assemblies etc.
Software was created with PlatformIO and C++. The system uses basic round-robin type scheduling to run all of its tasks. The sensors run in a separate state machine to the main loop and pass back information. The sensors are continuously scanned back and forth until they find a valid target weight. They then lock on to the weight and adjust themselves to remain locked on as the robot approaches. Math.
Robot position is tracked with the magnetometer and odometry wheels. This is fed to the navigation controller.
The navigation controller operates in two main states, weight steering and waypoint steering. The robot is in weight steering mode if the scanners have locked on to a valid weight. In this mode, the navigation controller uses the information from the sensors to steer the robot towards the weight and pick it up. Once the weight has been collected, the controller will swap back the main waypoint steering mode. This mode moves the robot between a series of "waypoints" in the arena. This is what defines the robot path. The robot will move between each node in order.
The robot path is set with the wayfinder application. This is a GUI application written with Python and Pygame. It allows us to modify node position and order, as well as assign behaviours and position tolerances to each node. Node types include generic path nodes, weight nodes, which tell the robot to look for weights nearby, and home base nodes which tell the robot to release weights. The wayfinder app also allows an image of the arena to be uploaded to assist with the placement of nodes. The images are taken manually from the upstairs balcony overlooking the competition. It is not directly overhead, so wayfinder allows the user to correct for perspective distortion and align the image to the known fixed arena dimensions.
I also developed a robocup simulator application. This simulates the movement and behaviour of the robot and ToF sensors. It allows us to test and iterate navigation code rapidly. It is written in Python, so the downside is having to convert the navigation code back to C++ for the robot.
The robot uses the following existing robocup electrical modules:
- Teensy 4.1 MCU module
- Power system module
- Button module
- Serial to bluetooth module
- IMU module
- Servo module (DC/DC converter and level shifter)
- Brushed motor driver module
- Consider the combine harvester design. It's boring but seems to work well for everyone.
- Try to keep the intake simple if possible
- Trying to collect every weight is not necessary, you can get a good placing by reliably picking up only a couple weights per round.
- Trying to design for picking up weights that have fallen over is not necessary, chances are they just roll to the side or can't be found anyway.
- The metal weights are actually quite heavy. Strategies from competitions like Vex where the target objects are lightweight plastic may not work.
- Test parts of the design individually instead of waiting until the end. If something doesn't work, you might have to redesign every other part that relies on it.
- Test early, especially the code, because there are issues that you cannot foresee until you actually get the robot running in a competition like environment.
- Don't rush code and make it a mess, this will make it extremely hard to debug.
- With a good intake, wandering around randomly worked very well for people. Designing all these complicated methods is fun and cooler but chances are it won't be any better unless you put a significant amount of work into it. *salty*
- 3d printing everything is fast and easy but not always the strongest. And tolerances can be a bit poor.
- Things sticking outside the robot can break.
- Consider vibrations, can make screws come loose. Made our sensor scanners vibrate and become less accurate as they moved around.
- Cheap servos are not accurate in the position, this was a major issue for me since I required accurate angles to detect weight position from sensors. They can also slip and click and vibrate and not work.
- Make your own drive pulleys for the main treads, because the metal ones they give you don't actually fit the teeth on the treads. You can get models from online for the given tooth profile for the tread. Consider the pulley diameter as this will change how you tension the tread. There are only so many slots to put tensioner pulleys.
- The robot will get stuck on walls and stuff. Add code to check if its stuck or hasn't moved. Then make it reverse, get unstuck etc.
- Use good connecters, make sure your wires aren't loose or hanging where they can get ripped out.
- Do a quick check of the robot before starting a round.