Assembling And Testing Your ELEGOO Tumbller Self-Balancing Robot Car V1.1
The moment has come, Eli has finally arrived! After weeks of waiting it was time to get down to business. The two things on my checklist? Assembling and Testing.
ASSEMBLY
Firstly, Eli arrived in a cute little box and was very well packed up, giving me peace of mind that all the components would be in tip- top working order despite the long journey to Roscommon.
Like a kid at Christmas I hastily unpacked and laid out all the various parts, making sure they were all there, as shown in the figure on the left! ELEGOO is a pretty good brand so I doubt you would be missing any, but it is good to get a feel of the parts all the same and also makes them easier to locate while assembling!
Having the parts laid out made it really easy to cross-reference with the instruction manual which, as you can see, included some great little depictions of the parts to avoid any confusion. The perfect visual BOM some may say. So far so good with this kit, very user friendly! Let’s see how we got on next.
The instructions continued to be incredibly intuitive and added to that the detailed knowledge of the assembly I had acquired from my CAD assignment, I was able to assemble my little robot in next to no time. In fact, I probably could’ve done it with my eyes closed at that stage! But for those not so familiar with all the intricacies of the assembly, fear not because as I said, the instructions require no deciphering whatsoever.
For each step you are told what parts you will require (far left of the picture) and even guided as to what appropriately labelled bags the necessary screws are located in (bottom left of the picture). From there, pictures depict how you should then assemble these given parts.
Not too hard at all, huh?
ELEGOO have also anticipated any common mistakes that might be made and have included pages dedicated to making sure you don’t fall into the trap! They are even colour coded in bright red to further ensure there are no mishaps.
The screws are pretty small and can be quite fiddly or easy to lose track of but thankfully if worst comes to worst there are spares provided for two out of the four types or screw. That being said, it is only one spare screw so do be careful! The kit does also supply a wee screwdriver so there’s no need to go rooting around the house or garage for one! Just remember-
Lefty Loosey, Righty Tighty!
There’s also no need to worry about which screws go where because as I mentioned earlier, the instruction tell you exactly and even point you towards what bag they’re in.
They all screw in super quick and easy but there is two that require nuts, situated on either side of the battery, so make sure you tighten them right up unless you want your battery slipping and sliding as your little robo-car zooms around the place. (And believe me, he can fairly zoom)
There’s not much else for me to say here on the assembly side of things. There’s definitely no need for me to explain each step as the instruction manual already does an exemplary job of that. So instead, I’ll just drop a few pictures here of some different stages of my own build! Enjoy!
Et vòila, the finished product! Complete with it’s own LED disco lights.
TESTING
So now that Eli was built, I naturally also wanted to get him up and running!
Now, when everyone else in my class switched their robot on, the robot jumped to attention. This was due to the pre-programmed code already uploaded onto the robots’ arduinos; unfortunately, that wasn’t the case for me. At first I fretted that I’d received a faulty kit but not to worry, the problem was easily solved. I followed the links provided in the instruction manual and found the source code here. From there it was just a matter of combining the programs and uploading them to my Arduino in these simple steps!
1. Hook it up
Using the provided cable, connect the usb end to your laptop and insert the other into the black Arduino nano (the left most circuit if you’re looking head on)
2. Open it up
Open up the program you want to upload. Here I’ve chosen the first program which controls movement of the robot.
3. Send it up
Press the arrow, highlighted in pink to upload your code. The yellow arrow beside it can be used to ‘verify’ or run your code before uploading. Once your code has finished uploading (this should only take a second or two), a message (as in the figure below) will appear at the bottom similar to what is shown once you verify your code only this time it will say ‘Done Uploading’.
So, if like me, your robot doesn’t spring to life straight away just follow those few easy steps and then you’ll be on the road to a whole host of fun with your new little friend/robot! You’ll be surprised with how advanced the little guy is; well at least I definitely was! There really is heaps of software pre-programmed onto those tiny little boards.
Unfortunately though, we’ve been tasked with operating something a little more difficult. We can’t simply let these pre-built-in functions navigate our maze and nor can we use the extremely cool ELEGOO BLE App, a sort of console control on your phone. Nope, instead we must manually programme our robots to automatically manoeuvre the course. (Blog post coming on that soon by the way so keep an eye out!).
But of course, I couldn’t pass up the opportunity to play around with some of these App based functions anyway… for ‘testing’ purposes of courseee… definitely not because I’m a big child.
Code I Enjoyed
So for any of you interested in the apps functions, once you download the ELEGOO BLE app you simply select the Tumbller then the rocker control and the following image is what greets you (minus the descriptions and arrows obviously)
The robot can actually carry out these various modes by itself once the right code has been uploaded onto it, and while it is pretty cool to watch him wander about by himself, having the ‘Bluetooth Control’ software uploaded gives you the remote control you always wanted as a kid.
Anyway these 6 main modes/functions, as outlined by the official ELEGOO page, are as follows:
- IR remote control: To control the car move forward or backward by pressing the arrow key on the remote controller.
- Auto-follow: While the ultrasonic sensor discovering the moving object in front, the car will follow up accordingly
- Obstacle avoidance: It can discover and avoid the obstacle in front and keep going.
- Bounce mode: Press the command key, it will tilt forward, and press the key again, it will stand up instantly and keep balance.
- Glowing mode: Tumbller has 6 colorful light modes, you can switch it freely as you like.
- Mobile control: With our newly developed ELEGOO Tool app, it’s very easy and smooth to control Tumbller using your mobile phone.
I’ve compiled a little video demonstrating a few of these. Hopefully it can give you a feel of how the robot moves and operates.
While these modes were all pretty cool to see in action, I don’t think pretty flashing lights are going to help Eli get around this obstacle course. Unless maybe he’s scared of the dark or something. But nonetheless it was fun to test out and get an idea of what this little guy was capable of.
Code I Found Useful
There was one function of particular importance though, the obstacle avoidance of course! I quite rigorously tested this mode actually in order to see to what extent I could utilise my sensors in the obstacle course. I tried to see how he’d cope in tight spaces as demonstrated in the video and also how he’d do in straight lines with walls either side of him. You’ll notice that this latter scenario wasn’t in the demonstration video… probably because the one or two times Eli actually managed it I wasn’t recording. The sensors (or at least the ones I received) really do vary greatly in their success, a fact that has slightly worried me as I start coding Eli for the obstacle course. I’m hoping that with some perseverance, and maybe a little luck, I can manage it anyway!
Code I Found Interesting
Out of pure curiosity and enthusiasm, I wanted to zone in a little on possibly my favourite bit of the tested code, a part that was at play in my previous video but that you probably didn’t think about. It’s not a function that I’ll be needing in my own code as I have to add a stabilising component anyway. However, seeing as I’ve had a bit of fun and also tested the functions I’ll need for the course, I thought I’d look into something that interested me a bit too… how the robot balances itself!
To initially demonstrate this and also to add a little bit of cuteness to your day, get a load of Eli and my dog Doug first meeting and then becoming the best of friends!
So as you can also see in the beginning of the video, Eli is pretty clever and as already mentioned, the source code that is supplied is pretty nifty. The instruction manual advises users to switch the robot on while tilted forward onto the front tray and from there there the robot can upright and balance itself! It’s some pretty advanced coding let me tell you that. The core idea of this balancing vehicle is ‘dynamic stability’ and based on data obtained by the MPU6050 module, the motors are adjusted by using a control algorithm in order to achieve the balanced effect. I think the following image (taken from the instructions) sums the overall objective up pretty well.
Based on this, you can definitely see in my video how Eli shoots back and forth at the beginning with the intent of achieving this equilibrium. Even as Eli moves around freely afterwards, this bit of code is still working as hard as ever to keep the balance even though the robot seems to move seamlessly. Believe me, if you remove this bit of code, the robot wont be long falling on his back, even with a stabiliser wheel on the front; unfortunately, I learned this the hard way.
But how do you actually implement all of this in code? Well it seems a pretty simple concept, right?… to anyone who isn’t too familiar coding that is. I was pretty overwhelmed when I first opened the scripts and was met with 100s of lines of intense coding. It was certainly more advanced than anything we had done before. But who doesn’t love a challenge? And after all, as our professor said, in practise it is unlikely we will have to code something completely from scratch as more often than not, you’ll be integrating your functions into code that already exists. So being able to read and figure out this code was great practise for what’s to come!
I figured that this little section above was controlling that overall, upright balance. Of course there is lines and lines of other code feeding into this but ultimately, this is what the final execution looks like.
The PWM (‘Pulse Width Modulation’) takes the digital signals from the circuitry and uses it to power and control the ‘left’ and ‘right’ DC motors and of course they’re being constrained to +/- 255 because as we know, that’s the maximum value of an analog output. There are also 3 basic control tasks required in order to achieve balance and they’re outlined in the manual as shown:
Having derived these three expressions, they are then combined with respect to each motor, ‘pwm_left’ and ‘pwm_right’. Based off of my own logic, I presumed that the sign of the rotation control differs for each motor because even though they’re both working in the same ‘forward’ or ‘backwards’ motion, they’re actually working opposite to each other. They’re a mirror image of each other and hence inverted. Thus, similar to antagonistic muscles, they perform opposite actions to produce a common effect. Though I do stand to be corrected on this.
Having obtained expressions for each of the motors states the code proceeds to inform the motors on how best to adjust given the latest data. The ‘?’ statements in the last four lines of code aim to check the state of the motor and hence perform either action (a) or action (b) based on the conclusion. In other words:
‘condition’
?
‘first expression’ (entire expression =first expression if condition is true)
:
‘second expression’ (entire expression = second expression if condition is false)
Note: I’ve structured these vertically just for clarity but obviously they should run horizontal.
Also in this section, should the predefined limits for angles etc (set elsewhere in the code) be violated, the robot can adjust accordingly in order to keep itself upright. It can even tell it’s been picked up if any ‘excessive’ angles are recorded that would not be possible otherwise. Upon this action I think the robot is supposed to stop but in fact it seems to go quite crazy and the wheels spin like mad; a slight but not terrible err.
As I mentioned before, there are also some limitations with regards to the sensors and Eli did seem to bash himself of the stairs and people’s legs rather a lot of times. Maybe he just wanted attention? However due to its faultless application, there’s no denying the balancing function is my favourite attribute of Eli’s. It has never failed once unlike those pesky sensors which, at times, had varying degrees of success to say the least.
Whether it be for the assignment’s sake, curiosity’s sake or just for the sake of some fun and childhood wonder, I think I’ve just about taken you through all my testing of the pre-programmed software. Now the real run and games is about to begin as I attempt to write my own!
I hope you’ve enjoyed my little assembly and analysis. I also sincerely hope I didn’t ramble on too much, the enthusiasm just seems to pour out of me and I can’t shut up! And now that Eli has arrived safely, there’ll be plenty more content coming thick and fast so stay tuned for some more in-depth posts!
Bye for now,
Aoife.
