Hi! My name is Rohan, and I am a first-year computer science major at Johns Hopkins. I am using hardware provided by ROBOTIS to build a quadruped, or four-legged, robot. Currently I am using four XL330-M077-T Dynamixel servos, an OpenRB-150 board, and an Arduino ultrasonic sensor(which I will later switch for ROBOTIS hardware). I will also be updating my progress here weekly. The GitHub link is here (code, CAD files, pictures, etc.)
This Week and the Week Prior
Hardware:
I made a prototype of the quadruped using cardboard for the frame. I also determined that there is likely a load issue, where if the quadruped is lying with its legs parallel to the floor, the servos don’t have enough torque to lift it back up.
Software:
Prior to this project, I had written some code to train another quadruped; this week I repurposed that code to run on the OpenRB-150 and with Dynamixels. This code trained the robot using a genetic algorithm. A robot walking is basically a sequence of when and how much it moves its legs. A genetic algorithm works by first trying many random sequences, then picking the two sequences which work best; then combining those two sequences to make more sequences, and seeing which of those work best; and then repeating. Some of my modifications to this code included
Removing a portion which stored the final sequence in EEPROM memory, since the OpenRB-150 doesn’t have EEPROM.
To counteract the load issue, I restricted the range of motion of the Dynamixels between 0 degrees and 180 degrees, so no leg would be lifted above the quadruped’s body.
An object which has four contact points with the ground(such as a table) topples over when the XY-coordinates of the center of mass lie outside the convex hull of the shape formed by those four points. This is assuming that the object is rigid; this is not true for the quadruped, as the servos are moving parts. However, I wrote code to make sure that, for the first set of random sequences, every sequence generated keeps the center of mass in the shape formed by the legs’ contact points with the ground.
Hardware
The software modifications by themselves didn’t fix the load issue. In order to test the code, I suspended the quadruped by a ribbon, to keep it from falling down permanently.
I also designed the 3D printed version in Onshape. In the 3D printed version, I included gears between the servos and the legs to increase the legs’ torques.
Next Week
Hardware
Next week, our university’s Makerspaces re-open. I first will lasercut the Onshape design using cardboard to test how well the gear system works. If it works well, I will 3D print the Onshape design and test it.
Software
I will write new code to train the robot around its center, while minimizing how much it moves forwards while turning(for precision). That way, it can move in multiple directions, not just forwards.
I will also write code so that the quadruped can adapt to different terrains, as opposed to only a flat surface.
Looks like that you got a very interesting project there!
Regarding the 150 and EEPROM, the 150 uses a SAMD21 and it does have some FLASH storage. But I am not sure that it will fulfill your actual needs, but you can have a look at my old post here and see it would be useful to you or not.
Another thing the XL330-M077-T is only suitable as a wheel drive because of the internal gear train used. If possible you can try to use the XL-330-M288 as it can deliver better torque.
Hi @roboteer ! I apologize for the late response(I only checked this post today). Thank you for the flash storage tip, I will try it out this week to see if I can use it. For the servos, I only have two XL-330-M288s, hence why I am using the XL330-M077-Ts.
Hello! Here is an update on the project. This week I 3D printed the Onshape design and tested it out, and got the quadruped moving. I included a video in the GitHub repository. We did have a snowstorm this week so I was only able to get the parts this Friday(and hence why this post is late).
This Week
Hardware:
I 3D printed the design consisting of a main body, four gears(although only two were able to print) and four legs. I assembled the parts with the servos and noticed a few issues with the dimensions — I had made the radius of the gears too big, and it was difficult to insert the servos into the body.
The gear system alleviated some of the issue with the quadruped falling down and not being able to get back up, although not completely. There was also a new load issue. I believe that this may be because of the friction between the body and the gear.
Software
Since our campus’s 3D printers are closed on weekends, I wasn’t able to reprint to resolve the aforementioned new load issue. Instead I tried to circumvent the load via software by incorporating interrupts into the code; I had noticed that when I unplugged and replugged the power into OpenRB-150, the Dynamixels were able to move for a few seconds. I thought an interrupt in the code might be able to simulate this(also I had never used interrupts and was curious to try them). However, this resulted in the OpenRB-150 no longer being detected by my computer, meaning I could not reupload code. I was able to eventually fix this issue using this post on the forum.
Instead of interrupts, I was able to use the Dynamixel library to reboot each servo periodically, which meant that the servos were able to move. Of course, this is not ideal, as the reason the servos stop moving is to protect themselves. However, it means that the robot can go through the training sequence uninterrupted.
Next Week
Hardware
I will build a chamber for training the quadruped to walk forwards. While I am mostly sure it will work, I would like to test it. The chamber won’t be anything complicated, just a thin cardboard box to make sure the quadruped can only move forwards and backwards.
I will fix the aforementioned dimension issues in the Onshape and update the GitHub. The forecast until next Saturday is mostly sunny, so I should be able to reprint the parts and test.
I will also build a chamber for training the quadruped to rotate. This will simply be a cylinder whose diameter is the same as the length of the quadruped, restricting the range of motion. The ground will have alternating black and white strips so that the quadruped can use an IR sensor to measure rotation, by how many stripes have passed.
Software
In addition to testing forward motion, I will also test the quadruped’s rotation using the second chamber.
@roboteer mentioned that the OpenRB-150 does have flash storage. I will try using it this week as I used the EEPROM memory in my earlier project.