This is the documentation for my Robotics Course Project created during my second year, second semester in FMI for the course Practical Robotics and Smart "Things".
Before I begin, I would like to acknowledge my parents, for their constant love and encouragement, not only for this project but for all of my previous and current endeavors. Without them, this project would not be the same. I would also like to thank the teachers of the teachers that guided me through the skills I needed to learn to make this project a reality. In no particular order I'd like to thank:
-
Dr. Ivan Chavdarov, for teaching me the skills related to 3D modeling & printing, as well as giving me guidance on my structural design by telling me what could be improved and how such things are usually made/designed.
-
Trayan Iliev, for expanding my horizons on the subjects of IoT and the software side of robotics.
- Getting started (click here if you just want to setup the robot and learn how to use it)
-
-
-
Structure overview (part evolution and motivation behind the design)
-
This project is for educational purposes only. This is my first robotics project and there are certainly bad practices/decisions that could lead to injury or damage to components. If you decide to recreate this please do so carefully. If any issues are discovered please put in an issue so I can fix it.
Also please note, this project is made by a beginner, I have never assembled, designed or programmed a robot before. When giving feedback or grading this please consider this.
This project has two main sections hardware & software. The structure of this documentation begins with the hardware aspects of the project because that is the way the development of this project began. After that, I will continue with the software side of this project.
The goal of this documentation is to inform the reader about the project and give him/her a better understanding of the project, what the motivations are behind the various design decisions and how the many hardware and software components interact with one another to create a complete robot as well. This document will also cover the many mistakes I made along the way, the challenges I faced as a complete beginner, how I overcame them. I also describe the lessons I learned along the way and point out the improvements that can be made if someone attempts to recreate this project.
Since this is my first project and documentation of such a scale I would like the reader to know that there may be some errors and things that can be done better. If you find such a thing, please make an issue in Github so I can get some constructive feedback and so I can improve this project for future readers.
For the reader's convenience, I have added “Back to top” links throughout the documentation, they will lead you to the beginning of the contents page if you wish to read another part of the documentation.
Since this is my first robotics project, the scope of this project is fairly limited if compared to the current state of robotics, but quite broad for a complete beginner. At the start of this project the scope was quite limited, but as the development progressed so did the scope because I discovered new things that would help me improve this project and teach me even more new things. I have more things I’d like to add in the future, I would also be very happy if this could be used as a beginners project for students or just people who want to get into robotics. That is why this will be a 100% open-source project so anyone can contribute.
During the development of this project in no particular order I wanted to:
- Learn about the platforms that are available for robotics and that are suitable for beginners but at the same time have enough room for growth in the future
- Using 3D modeling for visualizing the robot and as a key component in the manufacturing phase.
- Exploring different methods of creating the physical structure of the robot.
- How actuators are made/chosen and how they are controlled
- Learn more about key principles about robotics such as * Kinematics * How to deal with forces/balancing issues * Safety considerations when designing a robot * Motion smooth / using the quintic polynomial equation to manage forces on the robot caused by acceleration during movement.
- Learn how to make a basic multithreaded control software for the robot
- Facial tracking using OpenCV and implementing a PID controller to track a face by moving the robot.
-
Jog Mode This is manual control done via the encoders on the front of the electronics case. This is used for diagnostics and testing. This mode also shows off the multithread stepper motor control.
-
Program Path Similar to jog mode when it comes to controlling the robot, but there is an option for entering a node for a given position of the robot (both for gimbal and stepper motors). Once the wanted path is done, it is saved to a file and it can be replayed later using replay path mode.
-
Replay Path
Reads instructions from the selected file and replays them. A picture is taken at each node. -
Face detection & tracking This mode is still a bit experimental, but it does detect a face using OpenCV with Haar Cascade. Then with a PID Controller, it tracks a face attempting to keep it centered in the frame. I followed this tutorial, but I had to make a couple of changes to make it work with the C# code. More information can be found in the Unix Domain Sockets section.
The first choice I had to make was what kind of robot would be suitable for this project. The two main choices where either a mobile robot or a stationary robot arm. I know there are more options but considering my limited knowledge at the beginning I wanted to attempt one of the two types. In the end, I decided to make a stationary robot arm for the following reasons:
- Work environment - Before and after the pandemic my work environment was limited and setting up an environment for a mobile robot would have impractical. For a stationary robot, it was much easier to designate one small spot for it,
- Powering the robot - I only knew about lab power supplies and how they are used for such experimental projects, based on the knowledge my only reasonable option was a stationary robot as a mobile one would required batteries to operate freely.
Once I decided what kind of robot I would make the size of the robot was the next decision. Since I have a limited work area and limited resources such as time, money, and manufacturing capabilities I decided to make a fairly small robot arm that doesn't have practical use but is perfect for educational purposes.
Before beginning with the CAD design, I used Legos to create a crude model of the robot arm and the joints it would have and how they would move. I found this to be the best way to make the initial prototype as it cost nothing and gave a good enough visualization/feel.
- Work time - about 600-650 hours - aprox. 25-27days
- Print Time - 805h 8min - aprox. 33.5 days
- Total Project - 5.61GB
As this project has both software and hardware components I feel that it is necessary to list all of the tools I used during development
Hardware tools
- 3D Printer - Flashforge Creator Pro
- X-ACTO Knives
- Various screwdrivers
- Various pliers
- Clamps
- Soldering Iron
- Digital Caliper
- Wire-stripper
Software tools
- Visual Studio 2019
- Autodesk AutoCAD 2020 (Student Edition)
- Wolfram Mathematica
- Github Desktop
- WinSCP
- .NET Core IoT Libraries
- Flashprint (Slicer)
If you intend to build this robot, or even better, have already built it, this section is the one for you! The setup process isn't as straightforward as I would like, but considering the limited time, I think this is pretty good. The system is divided into two parts
- Client
- Server The server runs on the Raspberry Pi and the Client (console version) runs on any Windows or Linux machine.
Here are a couple of things you will need to get started:
- Visual Studio 2019
- WinSCP
- Basic Linux knowledge & ability to work in a terminal
- Command prompt or an SSH client such as Putty or Solar Putty if you want a better GUI
- A raspberry pi with the latest version of Raspbian (or as it is now called "Raspberry Pi OS)*
- .NET Core needs to be installed on your raspberry
- You will also need to install OpenCV
- If you are starting to build this, I suggest looking at the Fritzing connection schematics
- The parts list is also something useful as well as the STL Files may be useful for 3D printing.
I will describe how to run the client on windows, as that is the platform I have tested it on, but if you use the same steps used for publishing the server you will be up and running in no time!
- Once you have cloned or downloaded the repo, navigate to
Robotics-Course-Project > Robot Code > Robot_Codeand locateRobot_Code.slnand launch it in Visual Studio. - When everything is loaded:
* if you want to use the
GUI Client, findWindowsClientGUIin the solution explorer and run it * if you want to use theConsole clientlocate the ConsoleClient in the solution explorer - After that just press
Ctrl+F5to run
[Helpful tip ]: If you are new to Visual Studio, if the solution explorer is not visible you can search for it in the "Search" bar at the top of the IDE
1. Locate the Central_Control project in the solution explorer
2. Right-click and find the Publish option.
3. Once you press it, you will see this screen. Select the Folder option. Press Next
4. Select the desired publish path. Make sure it is easy to find since you will use it when uploading via WinSCP. Press Finish
5. You will now see this screen. Before publishing the configuration needs to be edited. Press the edit button.
6. This window will open and here you need to change the Deployment Mode and Target Runtime if you don't, it will not run on the Raspberry Pi.
7. Deployment Mode must be set to Self-Contained
8. Target Mode must be set to Linux-arm
9. The configuration window should look like this once you are done.
10. After that, you are ready to publish by pressing the Publish button.
11. This is how the output should look like if everything has been published correctly.
This section will not cover how to setup WinSCP, but it will show the basic upload procedure.
1. On the RPi create a directory mine is /home/pi/Documents/Robot_Code/Central_Control In WinSCP navigate to that directory (the right section of the UI).
On the left side navigate to the publish directory you set in the publish guide.
2. Select the publish folder and locate the Upload button. Then press it.
3. You will see the following screen, just press Ok
4. Then you will see this window, I suggest setting the upload speed to Unlimited if it isn't already.
5. Once uploaded the UI should look like this.
6. Now it is time to set the correct permissions. Open the publish folder and locate Central_Control
7. Right-click and press the Properties option.
8. For simplicity, just check all of these boxes.
9. Press Ok and you should be all set to run the server!
1. Login to the Pi via SSH (you can also use a monitor or keyboard, SSH is just a bit more convenient)
2. Enter your password
3. Navigate to the directory containing the program
4. Start the program
5. If everything has started correctly, you should see this message:
and you should see the notification LED's blinking like this:
Some known errors may occur during the starting of either the server or client.
- Arduino is not plugged in. This error looks like this and can easily be fixed by ensuring the Arduino is plugged in.
This section covers the design constraints I had during the development of the hardware and how the constraints affected the final design.
Since this project requires are higher accuracy of the parts and since I had limited time to make each part myself I decided that the best option would be to utilize 3D printing to make all of the parts for the robot. Since I also enrolled in a 3D modeling course in the same semester, the decision to use 3D printing would mean that I could apply the from one course in another.
The printer I chose for this project as mentioned in the tools section is the Flashforge Creator Pro. Since it was my first printer I decided to go with this model because it has dual extruders and the ability to print in a variety of materials, giving me enough options for the future.
Because all of the printing would be happening in my room, I decided to go for PLA as it does not emit toxic odors and it is significantly easier to print with. The strength of the material is adequate and is suitable for relatively small forces involved.
For the primary actuators, I decided to use two NEMA 14 35x28 stepper motors and for the gimbal actuators, I use two micro servos with metal gears for the rotate and tilt axes and a larger servo with plastic gears for the pan axis.
Due to lack of knowledge at one stage of the project I had to change the stepper motors from my initial NEMA 14 35x26 to the slightly more powerful 35x28. That said, I believe it is possible to make this project work with the smaller motors but better gearing would be required
Since these motors lack the holding torque to hold the arm of the robot horizontal or to even lift it, reducer mechanisms had to be implemented
As I am using 3D printing for making all of the parts I need to take into account the weaknesses and strengths of additive manufacturing to print good parts. Most of the parts are printed in a way that avoids overhangs as much as possible. Layer orientation is taken into consideration when possible.
To assemble all of the parts I use two main techniques:
- M3 & M2.5 machine screws of various lengths.
- Trapezoid wedges that slide into each other
The combination of these two methods allows for a good balance between the solid assembly of large modules and allows those modules to be connected using a universal attachment interface.
Note: Initially I used two other methods of assembling the robot:
- Friction fit connections with a square or hexagonal shape to allow for easy assembly/disassembly.
- Screws for all of the connections.
Both of these methods had significant downsides. The friction fit relied on tight tolerances, something that is not consistent when 3D printing parts. For the screw method, once the larger parts were connected, if something needed to be replaced, a significant amount of work needed to be put in to change a single part.
The structure of the robot is fairly simple. In the following points, I'll describe each part and all of the iterations I had to go through. The general goals for the hardware can be divided into two sections:
-
Robot structure
- It has to be printable
- The parts need to be able to support the expected forces and use as little material as possible
- The reducer mechanisms need to move smoothly
- As mentioned above assembly needs to be pretty simple
- Parts must be modular and easy to swap out
- Built-in cable management.
- It needs to look good (this has a lower priority, but still an important aspect)
-
Electronics housing
- There must be enough room to work inside and fit the electronics
- Cooling needs to be integrated into the case to help with performance
- Notification LEDs need to be in a good position for the user
- Any controls such as rotary encoders also need to be in an easily accessible spot.
- All ports that are used for connection to the robot need to be in the back
- As with the robot, it has to look good (again lower priority)
Some of the things mentioned in the electronics housing are described in more detail in the electrical system section.
I have decided to go through all of the iterations because I think it is important for me to show the whole process. That way I can describe the things I've learned along the way and it is a great section for beginners to see the mistakes I've made so they don't make them as well. Since this is quite a lengthy section I will provide skip links so that you can only see the final design or so you can skip directly to the software part of the project.
Since this is a stationary robot, the base is a key part of the design and a good base is essential for the overall stability of the system. This section also experiences the most loading and has to be designed with that in mind. I also want to cover the different adapters that are used to connect the arm sections to the base subassembly.
- Base & base drive train iterations
-
Iteraton 1 Initially, I started with this design. As you can see it is a simple and small gearbox and the larger gear has a hexagonal shaft. and it sits on a stand. The idea behind this was to have the rest of the robot be friction fit onto it, however, there were many tolerance issues. Another significant issue with this base, it had a small footprint and once the robot was friction fit ontop there was a lot of wobbling around and I abandoned the idea.
-
Iteraton 2 This iteration was inspired by the first version of the arm joint planetary gears and then a smaller version of this base gearbox was used in the final iteration of the arm joint. In theory, this setup should've been much more stable, but the way I chose to attach the base adapter created a lot of problems. This gearbox also had some binding issues in some spots, which resulted in irregular motion and the stepper motor losing steps. The problems mentioned along with the arm section issues at the base of the robot made me rework the entire base.
-
Iteraton 3 This is the final iteration. As you can see it quite different and uses a much simpler and adjustable drive train. In the base, there are 2 75 mm (outer diameter) bearings that provide the structural stability and smooth rotational movement. This base fixes all of the issues that the previous ones had and helped solve the issues with the base arm section
Thigs I learned - Its best to keep reducer mechanisms as simple as possible. It is important to consider the forces that will be exerted on a part, especially on the base of the robot. Bearings are something that should be used more often, they significantly improve the final result and are a great addition to 3D printed mechanisms.
- Base Adapter iterations This will just quickly cover the different adapters I made.
-
Iteraton 1 Uses hexagonal friction fit on one side and screws for mounting the arm section. Cons -
- No cable management
- Tolerance issues
- Time-consuming to mount/unmount arm sections
- Too thin for the loads it would experience
Pros -
- simple design
- quick to print.
-
Iteraton 2 This version as you can see it a bit better, but it still has the major issues of the previous one.
Pros -
- fixes thinness issue
- adds some stability due to wider footprint
Cons
- still time-consuming to mount arm sections
- still has tolerance issues
-
Iteraton 3
This one solves all of the issues of the previous ones but introduces some new ones. As you can see it is connected with screws to the gearbox, but those screws also hold the planet gears and carrier in alignment. This means that they can't be tightened too much as it will cause the gearbox to bind. Despite those problems, the easy swap functionality that comes from the use of a universal trapezoid mount allows for easy mounting of the other part of the robot. This base also has cable management that feeds the cables out of the back. -
Iteration 4 The final iteration of this part is removing it altogether. See the last arm iteration to understand the whole idea.
This is the most important part of the robot. It makes up the majority of the assembly and without it, the robot would not work. This part also transmits the most load and has to be made both light and strong. Many iterations were needed to get to the final version.
-
Iteraton 1 This was not thought through very well. As the previous first iterations, it relies on friction fits and too many screws to be practical.
-
Iteraton 2 This iteration is also poorly designed. While the shape is cool, it is too thin, too small and again relies on a friction fit.
-
Iteraton 3 This version is a bit better, much stronger but still too small and once again it uses too many screws.
-
Iteraton 4 This iteration is where better design choices emerge. There is proper cable management, it is light yet strong. Unfortunately, it is too complex and takes too long to print. It also uses too many screws.
-
Iteraton 5 This is the first iteration where a universal connector is used. The shape is simplified and there is better cable management. This design goes through 2 updates to make it stronger because it experienced a structural failure once. These updates just make the walls thicker.
-
Iteraton 6 For this iteration, the top arm section is the same, but the base arm section has been reworked due to the structural failure shown below. This change also comes from the redesign of the base drive train. As you can see, it still keeps the universal connector, it is also much more stable, compared to the previous arm sections.
This part is the one and only "joint". I call it a joint because it connects two arm sections in a mobile way. This part of the robot had a couple of requirements to meet:
- It needs to be strong enough (structurally) to lift the weight of the arm.
- Since the stepper motor can't lift the arm on its own the joint needs to be some kind of reducer with an appropriate gear ratio. The gears must also operate smoothly.
- It needs to implement a universal mounting system.
-
Iteraton 1 In the very beginning since I had never worked with stepper motors, I didn't know that they can't lift much on their own, and they require some kind of reduction mechanism. This is why the first iteration has no gears whatsoever.
-
Iteraton 2 This iteration uses a very simple planetary gearbox with a 7:1 reduction ratio. Was able to move the arm, but as it relies on a friction fit it is not stable. Along with those issues, after the gimbal iterations, it proved to be too weak.
-
Iteraton 3 In this version, I decided to try to make a worm drive, but since it is a much harder reducer to make it had internal friction issues that caused it to be too weak.
-
Iteraton 4 This is the final iteration and it is a smaller version of the second iteration of the base gearbox. It shares its flaws, but they were not as pronounced due to the smaller forces exerted on it. Using this new gearbox allowed me to finally add the universal mounting bracket to it.
-
Iteraton 1 As you can see there is more than one version, but I'm grouping them as the first iteration as they do not include any counterbalance. These are simple, they all do their job, but due to the weight of the gimbal, a counterbalance is required.
-
Iteraton 2 As you can see in this version, at the back there is a mounting point for the counterbalance mentioned above. This makes the job of the reducer much easier by balancing the forces.
- Iteraton 1 This part is pretty simple. Since I needed something to balance the gimbal, and an Arduino is needed to control the motors, I decided to combine the two and this is the result. The back has a tray for some metal weights and on the top, there are mounting holes for the Arduino. As mentioned above it connects to the second iteration of the arm joint adapter
This part also has a lot of iterations, as initially, I didn't know what the best approach was. All of the axes are controlled via servo motors.
-
Iteraton 1 This looks like a standard gimbal, the rotation motor housing is quite big and it is really heavy. Along with that, the camera mount is weak and the tilt and pan arms are also flimsy.
-
Iteraton 2 The second version of the gimbal is very complex and rather large. Due to this fact, it is very unstable and I quickly abandoned it.
-
Iteraton 3 The third version is inspired by the second one but attempts to minimize it by using smaller servos and smaller pieces. This design has major alignment issues. It is also very difficult to assemble and easy to break.
-
Iteraton 4 This final design is inspired by a project I found on youtube. I was already behind schedule and I thought that it's time to look for some help. I had to make the models from scratch since I am using servo motors and the person in the video is using brushless gimbal motors.
These don't have any iterations. I just bought a simple switch from the store and mounted it to the robot with two simple mounts. Despite their simplicity, these are critical parts as the allow the robot to "know" what position it is in. Please read the improvements section for more insight on the improvements I would make in the area of positional awareness.
This is a pretty simple part of the whole project. Its main goal is to make the project a bit more complete and polished. It also ensures, that once all of the cables are connected in working that they stay that way. The case also provides active cooling because it has two 95mm fans on one side.
Possible improvements
-
This housing it a bit large for the number of components inside, but since it was my first attempt at such a thing, I decided to leave enough space to work inside.
-
It also tends to tip forward as it isn't well balanced, so some legs or a flatter bottom might be a nice improvement.
-
Internal cable management can be improved
-
External cable management, such as ports for USB cables, ethernet, and so on. At the moment, all of those cables go directly out through the back opening. Ideally, it would have some sort of panel with the right kind of holes.
The schematics are very useful for anyone trying to make this exact robot. Please make sure to safely handle components and double-check connections before powering on the system. ***NEVER plug or unplug anything from the RPi or Arduino while they are working. ***
- Stepper motor connection schematic alternate link
- Encoder & switch connection schematic alternate link
- Stepper motor & stepper motor drivers * A4988 Stepper Motor Driver Carrier * NEMA 14 Stepper motor
- Encoders * Waveshare rotary encoder
- Single-board computer & microcontroller * Raspberry Pi 4 2GB is used as the primary computer. * Arduino UNO is used for servo control.
The electronics housing is not an essential part of the project, but it makes for a more complete and polished project. It also hides the mess of cables and provides an interface for the robot to connect to via standard ports.
There are 4 ports:
- Stepper motor A
- Stepper motor B
- Servo power & limit switches for stepper A
- I2C connection & limit switches for stepper B (Unfortunately I2C is never used)
- Putting everything on one PCB
- Increasing modularity by using even more universal plugs for other components.
- Adding microstepping control to the stepper drivers
- Utilizing the available I2C connection.
The software is the other big component of this process. It is responsible for the safe control of the robot. It is also the bridge with which the user interacts with the system. This is why I want to begin with some of the requirements that I decided are important for this project.
Since this is a simple robot, with limited functionality, I decided to make safety features as part of the functionality of the robot. Two main safety features are noteworthy:
-
There is a physical emergency stop button that is monitored by processes that control the stepper motors or send commands to the Arduino via the serial port. If the button is switched on those processes immediately stop the movement and exit to a safe program state. This check is performed before any movement code is executed.
-
There are physical limit switches that limit the motion of the robot and protect it from entering into dangerous positions. These are also monitored by the processes that perform movements. The difference is, that if a limit is hit, the robot can move back into a safe position if such a command is given.
These two safety-critical checks run on a separate thread and for each motor at the same time. All of that said, it is important to consider the platform and programing language being used, and the pros and cons associated with those decisions.
Along with the safety features, the robot has a couple of different modes of operation:
- Simple jog mode - control one stepper motor at a time.
- Multithread jog mode - control both stepper motors at the same time.
- Gimbal jog mode - control the gimbal - all axes at the same time.
- Record path - records a path, multithread stepper motor control, and an option to switch to gimbal control. Path nodes are set by pressing the correct buttons for each mode. More info can be found in the how to use section
- Replay path - Reads a saved file and replays the motion that was recorded.
- Face detection & tracking - track a detected face by attempting to keep it in the center of the frame (only works for gimbal)
This is an important category, as it is the way for the user to know what mode the robot is in. This is done via 3 LED's mounted on the front of the electronics housing. The main way the user can interact with the system with via the client application which has both a GUI and console interface.
Due to my limited budget and experience, the most reasonable platform was the Raspberry Pi and the Arduino UNO. Considering my fairly light requirements these two devices are more than capable to meet the requirements and perform well.
My initial choice was Python, but it was lacking TCP pending functionality that prevents blocking of the main thread while the server awaits a connection. I am sure some options allow for this functionality, but I was not able to get something to work. This issue combined with my lack of Python experience made me look for alternatives. Since I have previous experience with C# and since the Raspberry Pi is essentially running Linux my dad suggested that I look into .NET Core which can be run on Linux. After a bit of research, I discovered the .NET IoT Core library by Microsoft. It was easy to set up and quickly test and that is why the majority of the software is written in C#.
Note: 1. I am aware that C# is not the best language for a robotics project, but since I had so many other things to figure out, I decided that it was best to have at least one thing that I shouldn't worry about.
2. I am also aware of ROS, but I found out about it too late into the project for it to be possible to switch. 3. Despite the cons, for this current project, C# is more than capable of delivering good performance. This has been determined by simply working with and on the system for 5 months
As mentioned in the Key Features section, there is a mode for facial tracking. The problem is that is written in Python, but all of my other code is in C#. This means that I need some way for the two processes to communicate with each other. Unix Domain Sockets to the rescue! Since everything is a "file" in Unix, I can just create a simple server-client set up to allow the Python program to communicate with the C# cod that controls the servos.
This is a separate section because there is more to it than turning the motor on and off.
The standard way of moving a stepper motor with the A4988 driver is by pulsing the step pin at a given speed. For simple applications, this is more than enough, but since this is a robot and since there is a considerable amount of mass that needs to be moved, simply moving the motor from 0 to full speed is not possible. There are a couple of unwanted side effects of such instant acceleration:
- The stepper motor losing steps
- Extreme stresses that can lead to structural failures like this:
- Unnecessary wear on components.
A common approach that is used in larger robots is by using a polynomial trajectory to ensure that the robot moves from one position to another smoothly over time. By using such a trajectory we can imagine the position, velocity and acceleration curves looking something like this:
This is done by using this kind of a quintic polynomial equation:
where the function itself gives us the change in position, the first derivative gives us the velocity curve and the third derivative gives us the acceleration curve. All of these curves are given for a set time period.
Let's imagine we want to rotate the base of the robot from 0 to 42 degrees. There are a couple of options:
If it takes ~ 0 seconds to move from 0 to 42 degrees, the curves would look something like this:
Note: The Y-axis values are the value from the function and do not represent actual velocity or acceleration metrics
As you can see, both acceleration and velocity almost instantly shoot up, this causes a lot of stress on the structure and the motor.
Note: The curves are shown separately, to better illustrate the point.
On the other hand, if we use a polynomial trajectory, the curves look something like this:
After doing some research on the topic, I decided to try to implement this. Luckily for me, such a project has already been attempted and I am very grateful to Joseph Q. Oberhauser for the work he has done on his master thesis which has a part that covers this exact topic. I am also grateful that he has uploaded his C# code to his dropbox and still has it available at the time of writing this documentation. Even though it doesn't cover everything I needed, with the help of his work I was able to implement a working polynomial trajectory for my robot. It is not the smoothest operation, but that is mostly since I am not using micro-stepping and because my stepper motors only have 200 steps per revolution. Those two things result in quite a bit of noise, but overall everything works as intended and there is a visible improvement in performance as the stepper motor doesn't skip steps and there is less force exerted on the structure.
Due to the relative complexity of the system, I will not write too much text to explain it. Instead, I will use the things I learned in my Software Architectures course this semester to create diagrams for my system.
