Home
Welcome to the Atlas Project (earlier known as the JoMbot project). In this Wiki you can read about the Atlas project, why, how, and by whom it was performed, challenges, experiences, tests, results, tools, and software we used. For more information about using the robot and how to program it, check out the README page.
The Atlas project, (earlier named the JoMbot project), was made to test a master's degree class for Western Norway University of Applied Sciences (HVL) and HVL Robotics, to look for difficulties and provide the school width recommendations on how they could make the class more effective. We were two summer students, (Jobjørn Røkenes Myren and Martin Repvik Olsbø), working on this project together during the summer of 2023. During the project, our main goal was to build a robot arm, program it, and do a test run. We also looked into different challenges, tools, and software to this project and wrote down our experiences to this wiki.
So, this wiki page will serve as a log of the entire project, as well as a list of different articles about everything we learned about different tools, software and aspects of the project. You will find articles on a couple of tests we performed such as stressing 3D prints with plastic and tests on a 3D printed bearing and you will find articles about building a robot arm itself.
Note:
This project was conducted with access to a lab, and width the help from other collaborators which means that we got access to any kind of tools we might need. So, if you want to try out such a project for yourself, remember to check if you have the tools and recourses required to make it.
During the Atlas project, we used many different tools for drawing, printing, programming, and documenting the robot arm. In this list we have included many of the tools we used and provided information about what kind of tools they are, why we used them, how we learned to use some of the tools, and recommendations and experiences for others to use the tools. For an overview on the different tools we used, see the Tools, Software, and Experiences Overview down below.
- Fusion 360 (Fusion)
- Licensing
- Markdown (MD)
- Bambu Studio
- GitHub
- GitHub Desktop and GitKraken
- Visual Studio Code (VS Code)
- Python
- Dynamixel Wizard 2.0
- Heat Inserts
Fusion is a 3D drawing software provided by Autodesk. Autodesk provides multiple software tools for 3D drawing and other kinds of drawings if you are interested in more of Autodesk's tools check out their product site or visit their main website. Fusion provides you with lots of different options to draw, model, sketch, render, and visualize any 3D project you might want to make. Fusion also provides you with import options that you can import drawings and objects from other software's such as Inventor and AutoCAD as well as the ability to export 3D objects to other applications or 3D printer software's such as Bambu Studio that we are using for this project. More info about our use of Bambu Studio in its own article further down.
During our project we used Fusion mainly to design 3D parts for 3D printing, but we also used Fusion to visualize what our robot would look like when fully assembled to plan out functionally and limits. When we started out, we had little experience with drawing at all. We had both used Fusion before, but we knew little about the different tools provided in Fusion to effectively draw a proper 3D model and keep it easy to edit for later on. We knew how to create a sketch and draw by freehand to then finish the sketch and extrude parts from the sketch. We also knew how to use basic manipulation tools to shape the bodies or components into projects. But what we learned through a free 90-minute course provided by Autodesk if you have access to the software itself. And eave without the software you can still watch the videos and read the content of the course. If you do have an account and the software installed, you can download files from the course, upload the files to fusion and learn the features by doing in Fusion, so you get a learn by doing and reading experience. If you are going to take on any Fusion project, we strongly recommend taking the course if you haven't already. Here is a link to the course if you are interested: https://www.autodesk.com/certification/learn/course/learn-fusion-360-in-90-minutes. After using the software for a while, we also wanted to learn to use more defined parameters and learn to use user parameters for our components. User parameters gives you the ability to create variables that you can create your sketch dimensions from, and then later change those variables to suit your later needs or easier fine tune sizes on the go. You can also use your variables and automatically generated to calculate other dimensions relative to each other. we also found a similar course for this at Autodesk's web page. If you are interested, you can follow this link to the course page: https://www.autodesk.com/certification/learn/module/fusion360-intro-to-3d-modeling-associate-parametric-modeling-in-fusion-360:-sketching.
The software was easy to learn because of Autodesk's easy to use courses. If you wish to learn how to use Fusion or are going to take on any Fusion project, we strongly recommend that you take the 90-minute course before starting a project. This way you will get the best set of base knowledge you need to begin drawing, and you will get better results from the course if you use the features after you have learned them as in a project. To start out with Fusion we do not recommend the 2nd course we mentioned immediately when starting out. The course, or the functionalities taught in the course is for more advanced uses of Fusion. If you have been using Fusion for a while and are constantly recreating features or components to fit your needs, then we strongly recommend this course. As for basic uses you won't need it, but it can prove helpful in some cases. Other than the courses we mentioned, the Autodesk page is filled to the brim with different courses specializing you on different areas of Fusion. If you want to browse the courses for fusion, use this link: https://www.autodesk.com/certification/learn/catalog/product/Fusion%20360. You can also browse the page for courses regarding different applications other than Fusion. Other than the courses the best way to continue to develop experience in fusion is to use it for different projects.
Bambu Studio is a slicing software for printing with Bambu printers. We used Bambu Studio alongside with Fusion to create, slice, and print the parts for the robot. If you have used a slicing software before, it is easy to get into. But if you do not have any experience with 3D printing at all, we recommend that you try a couple of smaller prints first where you have to use the different options like changing the speed, temperature, support settings infill, raft setting, advanced settings and any other settings that would affect the print. Bambu Studio has their own Wiki page where you can read more about the printing process, the software itself and get a couple of tips to 3D printing. Here is a link to the Wiki page: https://wiki.bambulab.com/en/home
GitHub is our place of documentation and version control of any documents, codes, or files that we used for this project except for the Fusion files. GitHub is an online Git controller where Git is a version controller for projects. We use GitHub because it is web hosted, is free, makes coding new features for a project easier to handle, and is a good way to store the project with access for anyone interested. It was alite bit difficult to get into but GitHub is verry useful for making new features for any coding projects, as you can create a new branch for the feature and work on it without ruining the already functioning code in the main branch. If you want to know more about what GitHub is, here is an introduction video link. And here is a tutorial for GitHub.
GitKraken is a computer local Git controller, from which you can clone a remote repository from any Git providers such as GitHub to your local device and manage or work on your project on your desktop using preferred tools and software to later upload your changes through the controller. Alternatively, you can use similar controller applications such as GitHub Desktop or Visual Studio Code (VS Code) with the GitHub extension installed based on your preferences. During this project we used a mix of different solutions to best suit our workflow. One of us used the GitKraken app to as a local Git controller and VS Code to edit the project files. As the other one used only VS Code to do both. The only differences between the different methods of using a local Git controller is how advanced and easy to use they are. For example, in most cases you use a command line to clone, pull and push updates in the VS Code workflow directly in the VS Code editor, whereas if you are using GitKraken you get a visual controller to manage your Git repository as well as you can open and validate a merge request locally on your computer.
When you make a new project, we recommend using a license for your project. This way if anyone ever want to copy and use your project, they have to follow certain rules for using and redistributing copies of the software. Licensing a project on GitHub was easy. On the creation of a new repository, in the creation form you get asked if you want to include a variety of license templates. We had no idea what a license was and why we would even choose to use a license, so we skipped this step. Since we created our repository without the license file, we had to create a new file manually but even in the new file editor you had a list of different licenses you could just use. We had difficulties with picking the license as we didn't quite know what to choose. So, we found this webpage choosalicense.com that helped us choose between multiple licenses based on our needs and viewed every term, conditions, and restrictions associated with the licenses. We also found a page containing information about why it is a verry good idea to license your project or repository.
Here is a link to choosealicense.com: https://choosealicense.com/
MD language was also pretty easy to get into. To write the pages we started fairly early to get into the MD language. Upp till now we haven't used many video tutorials. But a cheat sheet we found, a GitHub template we were provided with, and some Google or Stack Overflow. The cheat sheet contains a verry detailed list of syntaxes and how to use them and also links to more information on every specific topic if the cheat sheet was not clear enough.
Here is a link to the markdown cheat sheet: https://www.markdownguide.org/cheat-sheet
And one more useful link https://docs.gitlab.com/ee/user/markdown.html
During this project we used Python as our programming language. We used Python to program the robot itself, to connect our computers to the Dynamixel motors and to drive them. We also used different libraries like Adatools and Dynamixel SDK (SDK) to help us program the robot. More about them below. Learning to code was easy as we both had experience from before with programming and programming languages. We made to different programs, one using Adatools and one using the SDK. As we learned to program, we began to structure our code better. to start out we used the example codes that we were provided with to test and learn the original codes from the libraries, and so on we took what we had learned from the original test codes and made our own functions and class while using the SDK to better run the robot. More about the class, its functions, and how to use them you will find on the README page.
Adatools is a Python library we used to design and visualize the kinematic structure virtually of the robot. It was quite easy to install as the README web page (direct link) had clear and simple instructions about how to install the library. The library itself would have been a bit trickier to start using, as the GitHub Page (direct link) only contained example codes with the most general usage for function the library. This should in theory be enough to learn how to use the library, but what would make it easier to learn would be to have a portion in the read me as a descriptive page of what each function and its settings did. It would not have to be verry detailed but give some clear instruction on how to use the functions. Luckily, we got help from the creator from the library to understand how the different functions are to be used, and the understanding of the library was incredibly much easier.
The Dynamixel SDK (link) plays an important part in effectively communicating with the arm. The SDK includes functions, classes and tests for a handful of common languages like C, C#, C++, Python, Java, Matlab, LabVIEW and Ros. Naturally we used the python version of the library. Again, here as with Adatools it was easy to install and use, but extremely difficult to get into as there where only examples of the code, and not actually descriptions of the functions anywhere. Whenever we needed to do something with the robot, we only had the example code to guide us with, and a FAQ that rarely gets any replies. Eventually we discovered what made the connections connect, and the robots move. We then took what we had learned from the code to make our own class with functions for setting the robot properties, and to make any movement or action reduced from lines of code down to just a function call with some basic parameters. Further we could not find any way of setting important dynamixel properties such as speed, acceleration, or movement modes. We knew it was possible through the dynamixel wizard, but we could not find any way to set such options through the Python code. We had our trials and errors to search for the parameters anywhere. But could not find out how to do it. More about the classes and functions and how to use them you can find at our README page.
The Dynamixel Wizard 2.0 software serves the purpose of connecting to and initializing the Dynamixel motors that we are utilizing for the robot's limbs.
Heat inserts most of the robot parts are just 3D printed pieces that were screwed together by some screws, but in certain cases we could not use screws alone, in those cases we used either nuts or heat inserts. Heat inserts are screw hole mounts that you can melt into your 3D prints by heating them up. In some cases, we had difficulties with just tightening the screws to the bear plastic, so we solved this by using heat inserts.
If you are going to try to attempt a heat insertion. We recommend that you do a couple of test prints first to test the best size of the insert holes and to get a better feel for the insertion process. When we made our inserts, we first tried to use a soldering iron without any tip attached. The surface of the soldering iron was then completely flat, and the thought was to then try to push the inserts as straight down as possible with the flat surface. The problem was that the surface was bigger than the inserts itself, and it was not easy to control the direction of which the insert was flowing with just a flat surface of the soldering iron. So, we attached one of the bolts' soldering tips with a cone like shape and inserted the rest with a little bit more control. For this project we like stated we used a soldering iron, but you can find tools to easier help you make better heat inserts. You can find soldering tips that are shaped to perfectly fit the insertions for better control during the insertion process, and there is even heat insert press tools out there to help you guide the insertions perfectly. And if you don't have the economy or just don't want to get the high-end tools for a tiny print job insertion, you can also get away with just a normal soldering iron and some practice.
During this project as with many others we conducted a few tests. These tests where all conducted out on theories or questions related to the project. This is a list of those tests and all of their documentation.
We asked ourselves what the best cross sections for this project would be in terms for arm strength of the robot. The reasons for these questions are the strength of different cross sections, and how to optimize the strength based on a limited amount of material. We had to optimize the material to be cost efficient, reliable and strong.
To conduct the test, we printed 4 different prints from tree cross sections. The cross sections we tested were a H-beam, a Donut Square-beam and two Square-beams. The two square beams had one difference, where one among them were printed vertically and the other horizontally. We also conducted the test twice on the H-beam as it has different results based on its rotations. So, we tested the H-beam standing up and lying down. In one of the two ends of the beams, we also put or drilled in wholes, with an equal distance from the end to easier tie weight to the beams. The cross sections where limited to 1 cm^2^ and the length of each beam where set to 173 mm. When planning the test, we were originally going for 15 cm but changed it to 20 cm. The 20 cm prints failed at 173 mm during the print as they tipped over. However, we decided that the quality of the 173 mm long prints was good enough lengthwise to use and printed the rest accordingly. The center of the holes drilled where positioned at the center of the beams, 17 mm from one of the ends.
Image of the different beams and where the holes were drilled.
During the printing of the beams, we encountered a couple of problems.
More on the problems listed, you will find under the 3D printing header in the Experiences section.
The test itself consisted of a bottle of water weighing about 616 grams, the beams, a flexible ruler, string and some clamps. To document the project, we used a camera with stand to take images, and we used a table to conduct the project on. The ruler was clamped down to the table with one of the arms, while the rest of it the arms sticking out of the table edge. We then used another clamp to clamp together all the arms of the ruler so we could use the ruler to visualize distances. Next up we used another clamp to clamp down one end of the beam to be tested and tied the bottle of water to the other end using the drilled whole.
Image of the settup we used to test each beam.
In the following table, you see the description of what we were testing, an image of the beam without the load and an image of the beam with the load.
| Cross Section Name | Beam Without Load | Beam With Load |
|---|---|---|
| H Beam Lying Down |  |
 |
| H Beam Standing Up |  |
 |
| Square Beam Laying Down Print |  |
 |
| Square Beam Standing Up Print |  |
 |
| Square Donut Beam |  |
 |
The Square Beam Laying Down Print where already slightly bent before applying the load. But if we compare the difference in bends between the Laying Down and Standing Up Squares, there is a slight difference between the two. Where the standing up print is slightly more bent than the laying down one. Then when we compare the vertically printed beams, we clearly see that the beam with the biggest bend change is the normal square one. Then ranging from the biggest bend difference to the smallest: #2 Standing H, #3 Donut Square and #4 Lying Down H.
Here is a table of ranges excluding the horizontally printed square beam print ranged by the strongest:
| Position | Beam Name |
|---|---|
| #1 | Lying Down H |
| #2 | Donut Square |
| #3 | Standing H |
| #4 | Vertical Printed Square |
The horizontally printed square was not included as the difference can be applied to the other cross sections Aswell.
Based on the different test results we found that the Laying Down H Beam was the strongest cross section. To make it even stronger you could print it horizontally. Also, during this test we used no kind of optimization formulars to find the best dimensions for each cross section, we only made sure that the area of the cross section was 1 cm^2^. So, if you would make the beams even stronger you could find out the optimal thicknesses for the Square Donut Beam and the H Beam as these can also have great effect on the result.
For a robot arm such as this we needed bearings to rotate the robots' joints. For now, we looked into some premade bearings and edited them to suit our needs. We found the bearings we needed at this Autodesk Instructables page, which contained 2 versions of the files. We chose the newest one as it was more reliable than the older one. We modified it to fit another set of bolts on the inner wall, resized the 3D model and printed a test file. After the print, the assembling process was easy. The only challenge was to correctly place each bearing cylinder as they were small and had alternating rotation. Here is the Fusion 360 file and the finished assembly:
The printed bearing seemed to be nice at first glance. The edges are a little rough and it did have some resistance when turning but nothing that we thought would cause any major issues. The inner circle was not perfectly ridged, as it had a movement margin close to 1 mm. Which meant that the print was going to have some margin of inaccuracy. We thought that there where ways to stabilize the robot by using some kind of support, base or another set of bearings.
In order to securely mount the motor, we identified the need for an affix that could be attached to the socket. To address this requirement, we opted to develop our own solution utilizing Fusion360, a design software.
During the initial test, it became evident that we had misjudged the positioning of the screw holes by a significant margin. Additionally, the affix shell proved to be too thin and lacked the necessary sturdiness. In response to these challenges, we took corrective measures by reassessing the screw hole positions and increasing the thickness of the shell from 1mm to 2mm.
Subsequently, the second test yielded improved results, although the screw holes were still slightly misaligned and too small.
In the third test, we succeeded in connecting the engine using two screws, but the remaining two screws were approximately 0.5mm off, rendering it impossible to securely fasten them.
Finally, in the fourth and final test, we achieved the desired outcome, as all four screws aligned properly with the design, firmly affixing the motor with minimal movement.
We have chosen a socket design that incorporates a pulley system in which a smaller cog is connected to the motor, providing power to a larger cog responsible for rotating the arm. This configuration enhances the mechanical arrangement by increasing its power output, albeit at the expense of reduced rotational speeds.
To secure the motor to the socket, we utilized the previously tested motor affix component. Additionally, to ensure the stability and proper functioning of the larger cog component, we opted to incorporate a small bearing at the bottom of the socket. This bearing facilitates the connection between the cog and the socket, while two larger bearings are employed to enhance overall stability and performance.
Upon printing the prototype, we promptly encountered several critical design errors. Firstly, we had utilized a 100% infill percentage, leading to warping of the print's sides due to material shrinkage. Our attempt to mitigate this issue by incorporating supports beneath the print may have inadvertently exacerbated the deformation.
Additionally, we observed that the presence of a wall around the affix hindered the insertion of screws necessary to secure the motor to the affix. Furthermore, the hole intended for accommodating the small bearing proved to be 1mm too wide, resulting in an improper fit of the bearing.
Another concern raised pertains to the insufficiency of flexibility in the affix component, making it challenging to precisely achieve the desired distance between the two cogs.
Overall, these issues necessitate improvements in order to rectify the aforementioned design flaws.
With the socket ready for testing, we prepared the Dynamixel Wizard 2.0 software. This software helps us detect the hardware and send instructions to the motor. We then gave some rotation instructions to see if the cog configuration would yield the desired result. However, the first time around, the distance between them was a bit too short, so we adjusted the motor a few millimeters away. The result was a robot arm socket that worked as intended.
During the project we had our fear share errors and solutions, and this part lists the problems we encountered as well as how we solved them.
During our project, we did a lot of 3D printing. The only parts we did not print was the rods connecting the arms, engines, and smaller bearings. We have had our fear share of prints failures that lead to practical thinking to redesign to make the parts better. So this is a list of discoveries we made to work around's.
The Stability Problem had to do with tall and thin objects. As the printing was done, the printer was shaking a lot. The printer was set on a table which amplified the shaking and resulted in the prints tipping over. To solve the problem, we decreased the acceleration of the print in the slicer software. We also made use of the slicer software's Raft function to make the print more stable. If you ever are going to print such prints, check the slicer software for the Raft function as well as the ability to decrease the acceleration.
The Base Deformation Problem or Warping Problem had to width the base of a print. When the area in contact with the print bed was too big, the print warped or shrank because of the temperature change in the plastic. On smaller prints this doesn't affect the print that much but the bigger the print base the worse it gets. This problem appears on bigger prints, because the more plastic you use, the more it will shrink when cooling. We found that one way to help this problem might be to decrease the amount of print in fill and to remember to use print glue. If you print a couple of times with the same layer of glue you used on your first print, you might see a difference in quality your prints as they get bigger. So, if you are printing something big, or something that has a big area of contact with the build plate, make sure to glue that area on to the plate to avoid the warping.
During the process of designing and printing parts for the Atlas, we have realized the crucial importance of accurate measurements and design decisions. We encountered both obvious and less obvious design flaws that necessitated reprinting or post-modification. These flaws resulted in not only wasted plastic but, more significantly, wasted time. To enhance the efficiency of the process, we recognized the need for greater precision during this phase. However, we also acknowledged the necessity of maintaining an open mind and flexibility to address any unforeseen flaws that may arise.
Screw holes where ok to manage. We did not use the thread function in Fusion. Instead, we made the screw holes a little bit bigger than the screw threads and used a nut at the other end to hold everything in place. In some places and cases, we could not fit a nut to tight the screws in place, so we used heat inserts instead. We also found out that creating holes for the nuts and screw heads in out parts made our surfaces look flusher as well as in some cases get the screw heads out of the way, so that we could use the space for moving parts instead. If you are creating some project where you are going to print anything and mount it with screws, do try to make the prints in such a way that you get the screw heads flush with the print surface. This will give the print a better final finish, save space, and save you a small amount of plastic. You could also make holes for the nuts if you use them, as well as cut the screws or get properly sized ones for your purpose, to make areas even neater.
We encountered issues with the robot's structure due to limitations in the cable lengths between the dynamixels. As a result, we needed to make adjustments to align it better with our initial kinematic structure plans.
To address the problem, we opted to make modifications after printing the parts rather than reprinting them entirely. The first adjustment involved drilling a hole in the lid connected to the socket, which effectively increased the range of motion for the first link. For the second link, we drilled a hole through the part where it connects to a vertical bearing, resulting in a 2 cm increase in the maximum link length.
Although printing new parts was a possibility, we chose drilling as it allowed us to save time and had a minimal impact on the overall performance of the robot.
During the initial phase of selecting joint configurations, our initial assumption was that we could engineer a robot that would exclusively exhibit favorable attributes while effectively mitigating any associated drawbacks. However, this belief did not align with our eventual findings. Through the application of offsets, we discerned the capability to significantly enhance the robot's range of motion. Notably, a substantial majority of joint constraints were attributed to instances of physical interference. As a result, the robot's operational proximity to the socket became compromised.
In hindsight, if presented with the opportunity to undertake the project anew, we would proactively explore the integration of offsets to optimize the robot's range. Additionally, we would adopt an approach that prioritizes enhanced coordination between the printed components, thereby precluding instances of collision and subsequently preserving its inherent flexibility.
This was a difficult task as we only had a couple of days left to master it and implement and use it in this project. For our project it was almost straight forward using it but the adatools preset zero value position was different from our robots actual zero pose. Calculating how to fit the offset in the already strange ranges of the tools where difficult as the minimum and maximum values of each joint where different, and the ranges waryating based on the minmax values. However, after a lot of calculations and leaps of faith we finally came to a functionality or mathematical solution that we believe works fine. However, this is not properly tested so be mindful for any errors if you ever use our cinematic structure programming, but if you do use it and it works perfectly that's great! It is not expected to work, but we did try.