Elegoo Tumbller build

Daniel Forrester
11 min readApr 10, 2021

For my assignment, I’m going with the original option of building and demonstrating the robot working. Albeit, I will still add a section in this blog referring to the design of the wheel regardless.

Assembly

I assembled the robot over a period of three days. On the first day I removed the robot from its packaging, inspected all the parts were present and read the instruction manual and online resources. I noticed some damage to some of the parts so noted it, documented and photographed it and flagged it with my professor.

The robot came in three sub boxes within the main box and an instruction manual. The various components were then gathered in small individual zip lock bags. I was quite impressed with the packaging of the robot. Various packages of screws were included each mini zip lock bag and the bags had a small sticker stating the type of screw and the amount, for example, M4*6 6PCS. This is really intuitive and helped speed along the assembly process.

The tools used to physically assemble the robot are a scissors and a screwdriver. The included screwdriver was a little small for me to use so I used one of my multi-tools instead. The assembly begins by attaching the two motor brackets to the aluminum alloy board. This was held in place then by 4 M3*6 panhead screws on each bracket.

Following from this, the two motors were attached. Care must be taken to make sure that the motors are oriented correctly such that the rotating shaft that protrudes from the motor is on the bottom half of the motor and is attached as low as possible to the bracket as seen in the picture above. This is attached with four M3*5 countersunk screws for each motor.

A coupling unit and M6 roundhead Phillips screws are then attached to the shaft and the screws are tightened to secure its position.

A wheel is then slid onto each coupling and a third M4*6 roundhead Philips screw is used to secure the wheel into the coupling.

The next step is to attach 2 copper columns to the clear plastic piece on the front of the robot with four M3*6 panhead screws in the clear plastic foothold. On my device this was horrendously scratched however, this damage, as prior stated, had been reported already.

The next step is on the Arduino board. A single M3*11 double pass copper cylinder is attached to the right-hand side of the board via 2 M3*5 countersunk screws. This cylinder is attached to the 1XGY-521 module. The 1XTB6612FNG must be checked to ensure that it lines up correctly with the schematic underneath it between the pins. If it is incorrectly orientated, now is the time to adjust it. In my case it was already oriented correctly.

4 more M3*11 double pass copper columns are now stuck onto the aluminum alloy board as seen in the diagram above and secured in place using M3*6 panhead screws. The Arduino board is then placed on top and held in place by more of the same screws. At this point the ultrasonic sensor is removed from its packet and pushed into its receiving slot in the front center of the board until a click is heard and the sensor is now securely installed. Care must be taken during this step to not damage the sensor or the board. In order to prevent this, I recommend placing one finger underneath the board roughly against the area where the sensor connector is located and attaching it in a pinching style motion.

We can now attach the four large M3*45 single pass copper pillars using 4 M3*6 panhead screws. The screws attach the columns to the blue alloy board. A clear U-shaped board is then placed on top of these four columns using 2 M3*12 pan head machine screws. I attached the battery box, then the two screws are held in place by 2 M3 K-type gear nuts. The wire can be fed through the hole in the corner of the board and attached to the Arduino board below.

The top of the four large columns protrude through the clear board which allows 4 M3*23 double pass copper cylinders to be screwed in directly into the top of these longer cylinders. This also acts to secure U-shaped see-through plate. On top of these new smaller copper cylinders we can now place the top plate on top of it and secure this using 4 M3*6 panhead machine screws.

I tackled the above steps over 2 days roughly split 50/50 as documented by the accompanying social media posts. On the final day I proceeded with the remaining last features. I attached the two 6P cables from each motor into the correct side of the Arduino board as stated by the instruction manual. I then preceded to switch on the battery and press the mode switch button and test the robot. I tested the robot in multiple modes but predominantly tested it in the auto-follow mode (https://www.instagram.com/p/CNbA97Cn0Nr/?utm_source=ig_web_copy_link). I was able to ensure that the robot would self-balance, that it would follow lead via ultra-sonic sensors and that it could turn. Having done this, I was satisfied the robot had no further issues.

Quality issues

I was disappointed in the build quality of certain parts on the robot. One of the motors had a shaft which could be moved perpendicular to its intended direction of motion. One of the pins on the Arduino board instead of protruding perpendicular to the board was bent so protruded at approximately a 70-degree angle and the 3 clear parts on the board were incorrectly manufactured. The top board had several holes which had not been punched or cut entirely through the board leaving a thin bubble of plastic at the end and the transparent parts generally were horribly scratched with chunks taken out of them and shards of plastic protruding. To me, it appeared as if these parts have been taken directly off the production line and scraped against the concrete cinder block for a good 60 seconds. Seeing as the packaging of the product itself has it as an ideal Christmas present, if it had been bought for its intended purpose, I would not have been a very happy customer. However, none of these impact the required functionality of the robot that it is required to do for these assignments and therefore I shall jog on.

Stabiliser

My robot when built would naturally balance via its code with the circuit board making a four-to-six-degree angle between it and the ground. This is due to the fact that the center of mass is in front of the motors on my robot. While this would allow my robot to ascend some hills, it could only do so at a very shallow angle. As a result, when I was designing my wheel attachment, I designed it so that the robot was leaning forwards at an angle of approx. 85 degrees.

Multiple approaches were considered when designing this wheel. A rough 3D designed being on SolidWorks to be printed was considered and while a prototype was in process of being drawn, I decided against printing as a 3D printed wheel will be significantly harder to modify than other options available to me.

I ultimately went with a Lego wheel. I was able to design it in such a manner that the wheel would be non-intrusive and act as a shell around the L shape part keeping it in place and therefore I would not need to drill holes in the forward platform of the robot to attach it. When removing it, I merely needed to remove the bricks. It also meant that if adjustments needed to be made to the wheel due to errors in my calculations it could be done relatively easily with the Lego as opposed to trying to lengthen or shorten a 3D printed print or organize a reprint mid-level 5 restrictions.

Coding

The final part of assembling this robot was testing the ability to download the source code, edit it and download it onto the Arduino nano. The source files were downloaded off the Elegoo website for Tumbller version 1.1 from the following link

https://www.elegoo.com/blogs/arduino-projects/elegoo-tumbller-self-balancing-robot-car-tutorial

At this point I encountered a difficulty. The source files are so large that the character limit for unzipping is reached and as a result I had to spend a lot of time troubleshooting. Ultimately the solution that worked was renaming the folder to 1 instead of its nice long name and moving it from the downloads folder to the C: folder. This reduced the file directory size sufficiently to unzip the tutorial code and PDF’s. I installed the Arduino IDE and went through the preliminary steps in the ‘copy me first’ folder and ‘tutorial 0’. These folders went through the basics of installing the relevant drivers and libraries and allows us to continue with the seven tutorial steps.

For the purpose of demonstrating code uploads and downloads, I only really needed to do the first tutorial on movement. I slightly modified the original code in order for the robot to move slower. I wanted to ensure that the stabilizing wheel could withstand the movement and that if the code didn’t work that the robot wouldn’t just run away from me leaving me to run after it. The code that was uploaded was a simple piece of code that moves the robot forward, backwards and then turned it left and right before looping and repeating. I did not need to test things like the ultrasonic sensor work as the pre-loaded source code was already tested when I initially checked the robot and things like the ultrasonic sensors were found to be working fine.

When downloading the files, we get several pieces of code for movement. We get the main piece of code ‘balanced_car’ and we get a number of sources and headings. In the motor.h file we see a number of public and private variables created as well as the pins being defined and the number of void functions is, for lack of a better word, initialised. Measuring_speed.cpp contains a number of functions mostly to do with calculating the speed of the motors.

In the motor.cpp file these void functions are defined as seen in the image above. Typically, each of these void functions are used to create a specific set of circumstances for the DC motors. If we take motor left and motor right as examples, the functions take the input integer variable speed and then ‘turning left’ it assigns the left motor to turn at the speed variable value and the right motor is set to 0 and vice versa.

Finally, we reached the main script. I made a number of changes here albeit small. I defined my variable speed to be 50 rather than 150 as in the original code. The code continues then to go through the typical set up stage and then we reach void loop. A rather nice loop function was set up here however I wanted to ensure that I could edit the code and upload the edited code and get it to work. The tutorial PDF showed that the fancy ‘for loop’ that had been put in here was equivalent to the more basic code as evidenced in the above picture. As a result, I merely copied the more basic code as I knew that this code itself was functioning and preceded to upload the code to the vehicle. When the upload was complete then I switched on the battery pack. The vehicle executed the ‘for loop’ and after two full executions (as demonstrated on the Instagram page https://www.instagram.com/p/CNfgOa4nUvi/?utm_source=ig_web_copy_link) I was satisfied and switched the car back off again.

Assignment debrief

Overall, I’m happy with how assignment one turned out in spite of its challenges. While the COVID pandemic has affected how a lot of modules are delivered, it certainly has not impacted on the development of one’s problem-solving skills. When designing the CAD, we did not have the physical robot in front of us. As stated before, one student acquired a private copy and had managed to send on some limited technical data and measurements on it. However, smaller detail was not provided and methods such as the sketch feature option from images acquired online as well as estimations and eyeballing all had to be used to create our robots in the end. Ultimately, I’m quite happy with how my CAD robot turned out. I believe it looks well and is as accurate as I could have been to the real robot given the circumstances. Having assembled the real robot, the only significant difference I’ve noticed is the top of the ultrasonic sensor is a lot closer to the plate above it than in my CAD design. However, this would merely just be a case of shortening the height of the extruded columns on the body. Unfortunately, the robots took a lot longer to arrive than anticipated due to COVID problems and the robots themselves did have challenges as stated above. Mine had some minor defects to it and I had some technical issues trying to download and unzip the source code for the robot which probably took me longer than any other piece of the second half of this assignment. However, all issues were overcome. Ultimately, I have a nice little robot with a functioning stabilizing attachment, some source code, some demo code and a high-quality set of CAD drawings to accompany it. Despite the challenges I’m quite happy with how everything turned out now it’s time to push on and tackle assignment 2.

--

--

Daniel Forrester

3rd year Engineering (Mechanical) with management student at Trinity College Dublin. Army Reserve at Irish Defence Forces (Logistics staff)