Assembly and Testing of the Tumbller
26th March
The robot has arrived! I collected it from College yesterday (25th March) and started assembling it this evening. It was great to finally get my hands on the Robot.
Assembly, as predicted, was extremely simple and intuitive. There were no issues regarding screws or parts missing. Everything went extremely smoothly and I followed the process laid out in the manual to the letter. Ironically, having the CAD model done in advance of receiving the actual robot made assembly a dream. In-depth knowledge of the components made this a very simple process. Anyway, I’ve given a brief outline with pictures below.
Assembly
I started by assembling the base of the aluminium plate to the motor brackets and connected the motors, wheels, and couplers. One weird thing I noticed was despite the motor bracket having 6 holes in it, you only
Next up, the foothold, Elegoo board, and ultrasonic sensor. These were all connected via standard screws and copper cylinders.
Another relatively simple process connected the battery box to the elegoo board and added the fastener, top plate, and copper cylinders.
Finally, wires connecting the Board to the motors were added and we’re off! That’s the assembly completed. I’ll start testing tomorrow when I get a chance. I’m curious to see what the sensitivity of the Ultrasonic Sensor is and how well it balances. I also need to add an attachment to allow it to stand up while stationary. (Notice the pen holding it up against the wall). I also decided to keep the foothold and plate coverings on for as long as possible to keep it clean.
Hardware Testing
26th March
A terrible start… I flicked on the switch and nothing happened. After being very concerned I reviewed my assembly and noticed that it was just a simple case of the wires not being fully plugged in to the board and motor. After I fixed this, we were off. I’ve noticed that whenever I first switch the robot on, it falls over a lot of the time, I’ll have to look into this more.
So basically the robot is pre-programmed. However, to challenge us a bit more, we’ve been tasked to make the robot automatically go through the obstacle course. We cannot use the pre-built-in functions, nor the very cool Elegoo BLE App that allows you to essentially drive the robot. That being said, for testing purposes I thought I’d check out the modes.
Here are the 6 modes from the Official Elegoo site below;
I’ve tested all these modes via my Instagram: @ciaranoflannagain_engineering which you can view by clicking the link. I’ve strung together a quick video testing all these modes and other various important functions
Follow Mode 1: Will follow an obstacle when the Ultrasonic or IR sensors detect it.
Follow Mode 2: Will move away from an obstacle when the Ultrasonic or IR sensors detect it.
Obstacle Avoidance Mode: Will move forward but avoid obstacles when Ultrasonic or IR sensors detect an obstacle.
Other modes include Balancing, Glowing Mode, and Bounce Mode. I didn’t focus too much on these as they weren’t as relevant to the project given the attachment being added.
They were all surprisingly accurate, the sensors seem like great quality and quite sensitive. There are obviously some areas the sensors can’t see, like anything below the board itself. This will have to be factored into the obstacle course construction. The ‘bounce’ function also is a testament to how sturdy the robots are, giving me a lot of comfort when it falls over. Next up is to play around with the integrated Arduino IDE software and see if I can upload codes and make various adjustments. **It’s also worth noting for future programming that I’ll need to slow the robot down significantly when moving to ensure the sensors have time to detect obstacles and make necessary adjustments.
Software Testing
31st March
Managed to connect the Robot to the Laptop and connect to Arduino. It took a small bit of configuring and installing drivers but I had no major issues. The main test involved with this was to see if I could burn the correct program onto the nano board. I did this by uploading the ‘Blink’ function. This just makes the board’s LED blink. Even though I won’t be using this function, it allowed me to prove it was possible to transfer code over.
Above are the various pins and the functions they’ll carry out for the Arduino Nano. I’ll be going through the exact intricacies of my code in my obstacle course blog, but for now, that’s most of the testing done.
Attachment Design
2nd April
The self-balancing Elegoo Tumbller only balances when it’s active, however what about when it’s turned off? I’ve been tasked with designing a rudimentary attachment that allows the robot to balance itself when stationary. I’ve been casually focusing on the attachment design ever since I got the robot. Some design considerations involved were as follows;
If there’s one thing I have an abundance of in my household, it’s LEGO. It’s perfect because it offers wheels, which are one of the most design specifications needed. I built many different variations of prototypes for the attachment but attaching them resulted in the Robot going haywire when I turned it on. I’ve determined that the self-balancing function is significantly hindering the ability to attach the attachment. I plan to REMOVE the balanced car Arduino code from the equation altogether when I finally get coding. Therefore, I can’t properly test the effectiveness of the attachment until coding takes place. For now though, here are some design variations I constructed.
Design Concepts
Design 1: One Wheel — One Axis of movement
This preliminary design just consists of one fixed wheel attachment to the foothold via bulldog clips. I’ll swap these out for some permanent adhesive when the design is finalised. The wheel can spin, but the part as a whole is fixed connected to the foothold. I’m uncertain whether the rotation is needed around the Y-axis, this will be further determined when testing takes place
Design 2: Two-wheel — Two axes of movement
Similar to design 1, except it can swivel around the Y-axis (where the blue link is). This replicates a caster wheel with two wheels. Trying to get both wheels to touch the ground while attached proved difficult.
3rd April
Design 3: One Wheel — Two axes of movement
This is the design I’m currently the happiest with. The simplest and most effective looking. I removed the second wheel from design two.
Above shows the axes of movement, this will allow the wheels to change direction to coincide with the main wheels. This design allows for a far more fluid motion of the robot when it comes to turning. This is the attachment that I will be moving forward with. I may be making some possible adjustments to the attachment as we move towards testing because that’s the nature of design. Any further changes to the stabiliser will be noted in the obstacle course blog.
