RoBug - tiny robot, big attitude

RoBug - tiny robot, big attitude

Hey there, thanks for stopping by. You just found the RoBug project on hackster.io! So let's take a closer look...

The main goals of this project were:

• to create a small, friendly quadruped robot that can interact with us by expressing his "mood" visually and through "body language"
• an open, feature rich, yet affordable robotics hardware platform that isa) easy enough to build for educational purposes) powerful enough for in-depth robotics experiment
• an open and modular software architecture that makes it easy to develop robotics applications by providing an easy-to-use framework with a high-level API written in MicroPython
• building a digital twin that can be used in simulation environments like pyBullet, Webots, Nvidia Isaac Gym, Gazebo etc. for testing, development of new motions and to be prepared for reinforcement learning experiments.

Walking is a fascinating way of locomotion. Making a quadruped move in a natural and fluent way is the hardest part of the project but also makes a legged robot stand out. Actually when it comes to walking that's where many DIY robots struggle. RoBug comes with a ready-to-use ik solver, gait generator and motion controller that allows for a smooth, dynamic diagonal gait, that is adjustable in speed, stride length and body height on the fly.

Cost was an important aspect in the design of RoBug because the lower the overall cost, the lower the risk, the lower the barrier to build this project. Depending on where you are located, the required parts will total up to about 60€ to 70€ plus 3d-printed parts.

Feature Summary

• special 2DOF leg topology for wide range of motion
• low body weight and speedy servos enable dynamic gaits
• compliant foot tips to absorb shock and conserve energy when walking
• PWM-controlled LEDs in the "eyes" can express RoBugs mood
• Touch sensors on RoBugs back and belly enable hand contact detection
• ToF distance sensor for obstacle detection and avoidance
• Raspberry Pico 2 WH with enough compute power and I/O
• Wifi and Bluetooth (traditional and low energy) thanks to the Pico 2 WH
• Open-hardware RoBug Base Board for easy assembly
• Full open-source software stack written in MicroPython
• RoBug Quick Start Application Template
• URDF and Webots PROTO simulation models

Sounds interesting? Want to build your own? Then just keep on reading and take a look at the part list and the extra part list with links to vendors in the download section. Shouldn't be too difficult to get a set of parts for reasonable money.

Construction Considerations

I'm a passionate Blender user for over two decades so I'm using it for all my constructions. Blender is such a flexible software package and there are many plug-ins around for 3d-printing, mechanical design and export into lots of formats. STL? No problem. URDF? No Problem. Inverse kinematics for testing the range of motion of a joint? Come on, this is an animation software. It's even possible to use Blender as a gait development tool since you can export animated joint trajectories into CSVs easily. And you can use the full set of animation tools to do this! Ok, I'm not gonna lie, there are a few downsides, e.g. so far, there are no shape objects that can be parametrized but with plug-ins, geometry nodes and modifiers it's getting close. I guess CAD people will strongly disagree but in my humble opinion, Blender is close to ideal for robotics. The complete Blender design file is available for download in the attachment section.

The leg design might look a little bit different compared to the "standard" quadruped robot. But that's for a reason. One of my main interests is how walking works. This leg design enables a wide range of motion with only two degrees of freedom per leg. The body height over ground is very flexible. So the center of mass (CoM) can be set very low for stable static gaits or higher for dynamic gaits. For advanced motions, the feet could even reach the top of obstacles to climb over it.

Finally, I wanted some sort of a compliant foot tip mechanism to absorb shock when the feet hit the ground and to equalize small bumps and dents of the terrain. This will stabilize the robot a lot when walking and help to keep the balance in dymamic gait styles. The caps at the and of the feet can slide in and out a few millimeters. A small compression spring inside the caps makes the foot tips compliant.

Quadruped Gaits

There are basically two groups: dynamic and static.
A dynamic gait has a phase in which the robot is not statically stable. For robots with four legs, that usually means that less than three feet are on the ground at the same time. If this phase lasts too long, the robot will tip over.

The body position below enables very quick movement of the feet without too much activity of the femurs. Why this is good? The knee joint motors are attached to the end of the femurs. If they have to move around a lot to reach a certain foot position, the robot will be exposed to dynamic forces that can destabilize a dynamic gait. Dynamic gait means that there are less than three feet on the ground Here, the femurs only lift the feet a little bit. The stride distance is achieved by tibia rotation, which is very light weight and has a low inertia. This way it is possible to achieve a nice dynamic diagonal gait even with a relatively simple leg configuration.

In contrast to the dynamic gait, in a static gait the robot has at least three feet on the ground at any point of time. You can see how the CoM projection (light green cross) is always inside the support polygon that is spanned by the feet that have ground contact. You could stop the walk cycle at any point in the walk cycle and the robot would just rest in this positions forever.

The scenario above in turn enables a really stable static gait due to the low center of mass. But the knee joint has to move around quite a bit to reach a certain feet position. The accelerated / decelerated motor mass in the knee joint will generate dynamic forces that can easily tip the robot when less then three feet are on the ground, so this pose is much better suited for static then dynamic gaits.

Microcontroller Board

As for the microcontroller choice, there were a few things to consider given the very limited space offering inside RoBugs body. The microcontroller board plus all the wiring, sensors and the battery has to fit into the body enclosure.

• Power supply: since space is so limited, there's no space for additional DC/DC converters. The microcontroller board needs to be powered directly from the battery.
• PWM: there's no space for an additional servo driver board, so all the servo control signals need to be generated directly by the microcontroller. There are eight servos plus two LED channels. So at least ten independent PWM channels are required.
• I2C: at least one I2C interface is required for the distance sensor. A second one is nice to have.
• UART: a UART interface to communicate with a supervisor SBC is nice to have, e.g. the microcontroller handles all the motion related tasks and receives high level commands from an addtional small SBC that is running a camera for advanced navigation.
• ADC: at least one ADC channel is required for battery voltage monitoring. More channels are nice to have.
• Pin I/O: at least 2 digital Inputs are needed to capture the state of the two touch sensors. The more the better.
• Wireless communication: again, due to the space limitations, there's no space for additional expansion boards, so onboard Bluetooth and Wifi is required for remote control and telemetry applications.
• Performance: communication interfaces, sensors, the motion controller and the gait generator have to be evaluated and updated in a precisely timed loop, e.g. every 10ms. The more headroom the better to be prepared for more complex applications.
• Memory: ideally large enough to load small ML models, e.g. using tinyML, TensorFlow Lite etc.
• Ecosystem: A large and active community helps to find useful packages, find solutions for problems and provide long term support.

Eventually, I picked the Raspberry Pi Pico 2W. It comes with a nice and small form factor of only 51mm x 21mm, a wide input voltage range up to 5.5V, up to 24 hardware PWM channels, three analog channels, two I2C interfaces, two UART interface, plenty of digital pin I/O, Wifi, Bluetooth and a strong dual core Cortex-M33 MCU with 520kB of RAM. The Pi Pico comes with a MicroPython SDK and has huge community support. All in all a perfect fit for RoBug.

Power Supply

in my humble opinion, the power supply concept is a very underestimated aspect in many DIY robot designs. A solution often found is a 1s or 2s LiPo battery and a DC/DC converter to generate a 5V rail for the microcontroller and the actuators together. For any robotics project I highly recommend to power the motors directly from the power source, i.e. the battery. DC/DC converters, in particular the cheap ones, might have problems to deliver the highly dynamic currents the motors draw when the legs move quickly. The voltage drops and in the worst case the microcontroller browns out. Don't get me wrong, nothing speaks against DC/DC converters to generate the microcontroller supply voltage. But remember, the best component is the component you can omit. It will save you space, complexity and last but not least cost. So if there's a way to power motors AND microcontroller directly from the battery, do it.

RoBugs is powered from a 4s NiMh AAA battery with a voltage range of 4.8V to 5.6V, just perfect for the Raspberry Pi Pico 2W. The same voltage can be used to supply many common servo motors too - check.

Actuators

• Power supply: the actuators will be powered direcly from the battery. Assuming a 4xAAA NiMh battery pack, the input voltage range should be be around 4.8V to 5.6V.
• Torque:RoBugs tibia is about 110mm long. Assuming a total weight of max. 500g and a minimum of four feet on the ground, the required minimum torque will be about 0.135 Nm or 1.35 Kgcm. With only two feet on the ground, twice the torque would be required. But the requirements can be reduced to about 0.125Nm with some acceptable limitations to the range of motion. This is really a minimum requirement and should be exceeded by the actuators to enable dynamic motions.
• Speed: to enable a really quick swing back phase during a dynamic gait, the actuators need to have a sufficient high angular velocity. It's hard to quantify this but from former experiments, the target should be around 0.1s/60°, the quicker the better.
• Weight: There will be 8 actuators for four legs, so the weight is really important here to keep the overall weight low. There will be one actuator sitting in the knee joint of each leg. This will add to the inertia of the hip joints. For quick, dynamic gaits it is crucial to keep the joint inertias and the effective leg mass low in relation to the body mass as low as possible. Otherwise the dynamic forces generated in quick gait can cause gait instability. Long story short: Actuators should be as light weight as possible.
• Size: Four actuators will sit in the body enclosure where space is precious resource. The remaining four actuators will be placed in the knee joints and should be small enough to fit into the targeted leg design
• Construction: the actuator shaft will be exposed to radial forces generated by the mass of the robot. In other word, the hip shafts will have to carry the robot. So we want at least one ball bearing for stabilization and a metal shaft.

Surprisingly enough, a very good actuator choice is the very well known MG90S servo. It delivers a stall torque of 0.24Nm, achieves an angular velocity of around 0.1s/60° with a weight well under 15g. MG90S servos are very affordable, for a little bit more money you can get a set of original Tower Pro parts. I do NOT recommend the "SG" types since their gears and shafts are made of Nylon and they don't have ball bearings. They are just not stable enough.
Believe me, I tried it :-)

Ok, let's do this

So here's the internal wiring plan, really not that difficult, especially if you decide to use the RoBug Base Board PCB.

Wire it up!

RoBug Base Board PCB:

If you opt in for the PCB, download the RoBug Base Board manufacturing data and order the PCB from your favorite PCB manufacturer. Once you have the PCB on your workbench, start with soldering on the 0805 SMD components. Footprints with slightly larger solder pads where used to simplify this. After all the SMD components are done, proceed with all the headers, connectors and other THT parts. Instead of soldering the Raspberry Pico 2 WH directly into the board, use two 1x20 standard 100mil female headers to the left of J16 and to the right of J17. J16 and J17 themselves are meant to stay unpopulated, they provide access the Raspberry Pico 2 GPIOs for custom wiring. As you can see on the schematic and the PCB render, there's a footprint for an optional ST LSM6DSL IMU right in the center of the PCB. This IC requires advanced soldering techniques, so I won't go into details here. Just leave the footprint unpopulated - we need some room for future updates, right ;-)

Optionally: Prototyping Board

Optionally, if you want to save a few bucks or you just feel like soldering, you can use a 56mm x 50mm piece of prototyping board instead of the PCB. Place the connectors roughly like they are placed on the RoBug Base Board and wire up the connections using silver coated copper wire and a few pieces of cable. Actually that's what I did for the prototype. You can refer to the simplified schematic below for the wiring but of course you have flexibility to place

Here's my take on the prototyping option for the base board. I used it for the RoBug prototype and it works like a charm :-)

Battery

Now it's time to assemble the battery. The four 800mAh AAA NiMH batteries from the part list have solder tags, Solder them together as depicted in the wiring diagram but make sure you get the orientation right. IF YOU MAKE A MISTAKE HERE YOU COULD DAMAGE THE BATTERIES OR EVEN HARM YOURSELF - so be careful here!

Cut the 1x2 female JST cable from the part list to a length of 8 - 10cm, then solder the black wire to the negative pole of batterie #1 and the read wire to the positive pole of battery #4. Wrap the batterie pack in insulating tape to give it some structural stability but don't go crazy here, not more than one layer of tape to avoid overheating of the batteries.

Use the rest of the cable, the power switch an the 1x2 male JST header to build the counterpart of the battery cable. Make sure you solder the red and black wire to the correct pins of the male JST header as shown in the wiring diagram above. Cut the red cable in half and connect the power switch to the two halves as shown. When soldering the male JST connector to the cable, work fast and precisely, otherwise the hot pins will melt the plastic of the header housing and become lose. Oh, and I highly recommend to protect all the soldered connections with some small pieces of heat shrink tubing.

Ok, take a breath, we're almost there, only the sensors and the LEDs are missing.

GY-530 distance sensor:

Take one of the 1x4 female JST cables from the part list and cut it to a lengtht of 8 - 10cm. Solder the cable to the GY-530 distance sensor as shown in the wiring diagram, Make sure you solder the cable into the sensor PCB from the BACK and that the solder pads are flush with the front PCB surface. Keep the GY-530 front side as even and flat as possible, you'll appreciate that when you mount the sensor into RoBugs head. You'll find a few pictures of the prototype assembly below - don't get confused, I used different cable colors, but you can stick to the wiring plan.

GY-530 and LED assembly :

ok, this is a little bit more manual work and it requires the 3d printed front cover insert to be available. So if you don't have the 3d printed parts yet, go to the 3d printing section and come back once you have printed all the RoBug parts.

Assuming you have the front cover insert ready gently push the pre-assembled GY-530 into the rectangular cavity so that the VL53LX0 sensor on the front of the PCB can "look" through the hole in the insert.

Next, push the four LEDs into the insert as far as possible. BEFORE you do that, make sure the cathodes (shorter legs) of each LED pair are pointing towards each other. Make sure the colors are in the correct positions. If the fit of the 3mm holes in the insert is to tight you can widen them carefully with a 3mm drill.

Now shorten the LED legs to about 5mm or a little less. Solder together the two cathodes of each LED pair. Then connect the anodes of the left and right green LEDs with a short piece of cable, followed by the anodes of the left and right red LEDs and finally the common cathodes of the left and right LED pairs. Now we have a common cathode for all four LEDs, a common anode for the red LEDs and a common anode for the green LEDs.

Eventually, take a 1x4 female JST cable and shorten it to 8 to 10cm. The red wrie will not be used at all so you can remove it completely. Now solder the black cable to the common cathode, the yellow wire to the anode of the green LEDs and the white wire to the common anode of the red LEDs, all on the same side.

TPP223 capacitive touch sensors:

Take one of the 1x3 female JST cables from the part list and shorten it to about 8 - 10cm. solder the wires into the TPP223 PCB as drawn. Again, make sure you solder the cable into the sensor PCB from the BACK as shown. Proceed exactly the same way with the second TPP223.

Congrats, you mastered tha RoBug internal wiring preparation section :-)

3d printing

All the STL files and the Blender design file (yes, correct, RoBug was designed with Blender) are are available for download. I added some screenshots to show how I arranged to parts on the 3d printer plates. The RoBug stand and the calibration gauge on plate 3 are optional but super helpful if you intend to develop your own gaits and motions. I printed everything with Babu Lab PLA Matte Ivory White on a smooth printing plate.

The only parts that need some supports for a good looking result are the front and rear covers and the fron cover insert. If you can print with support material I really recommend that - if not use simply use your default material for the support structures. See the image below how the sliced result looks for me without special support material. All the remaining parts are easy to print and straight forward.

RoBug Assembly

Here's an animation video that explains the final assembly of RoBug:

<Animiation>

Software installation

To setup your programming environment and install the firmware on your Robug, just follow the four simple steps below and you should be good to go:

• Thonny installation
• MicroPython installation on your Raspberry Pi Pico 2 WH
• download/clone the MicroPython code from the RoBug github repository
• Eventually upload all the MicroPython files to your RoBug using Thonny, if never did that before you can follow this mini-tutorial on youtube:

To test your setup, load led_test.py from the Pico into Thonny and hit F5. The LEDs in RoBugs eyes should smoothly transition between green and red in an endless loop. Works? Awesome, you're all set up :-)

Calibration

Assume the software sends the pwm signal for "0 degrees" (neutral position) to the servo motors. All the servos will rotate to what they "think" is 0 degrees. But looking at the result, you'll notice that some rotated too much while others didn't rotate enough. That's why we need software calibration. We'll try to find the angle offset for every joint that is required to compensate the angle error. Assume a servo motor rotated to 3° instead of 0°. In this case, we'll simply apply an angle offset of -3°. Easy :-)

run RoBug, run..

A few final words

I made everything that belongs to the RoBug project open-hardware/open source. I'm sure you understand that a lot of time, work, love and dedication went into this project. So if you decide to build a RoBug, do me one favor... post an image or even a short video. I would love to see what you created.

PS: Let me know if I used the word RoBug often enough :o)