- Building Prerequisites : Material and electronic components needed to build the arm
- Assembly Instructions : Step-by-step instructions to build the arm
- Control Software : Download instructions for a basic software to control the arm
- Download Instructions : Download instructions
- Code Architecture Documentation: General description of the software's architecture
- Future Work : Possible improvements
- Scholar Papers: The scholar papers that were useful to this project
- user:
cottus-pi - pass:
cottus-pi-s3cur3
Pieces that should be 3D printed can be found as .stl files in the Prints directory
Pieces that should be laser cut can be found as .dxf files in the Prints directory.
6mm thick MDF should be used for all laser cut parts. They are named according to the referential of
the arm's model in Fusion360
- [x16] : M4*12mm > Nema 17 Stepper Upper connection
- [x12] : M3*20mm > Nema 17 to Gearbox Adapter Connection
- You might not need these
- [x3] : Aluminium/Metallic axle : 8mm in diameter
- [x1] : Wood glue stick for MDF assembly
The Fusion 360 file of the entire arm that you can import can be found here. It
contains all the 3D pieces and sketches resulting in the .stl and .dxf files you can find in the Prints directory
The arm's controller hosts a server which the software's web client connects to in order to control it. The server opens a serial connection on startup to communicate to the Arduino Mega via predefined packets :
- From PI to Arduino : Target angles (In degrees)
- From Arduino to PI : Motor speed (At startup, in deg/sec) and Current angles position (In loop, in degrees)
The framework chosen to code the backend of the application is Quarkus. It is a recent framework resembling Spring Boot. It has a well documented API that I invite you to check here.
Several libraries act on top of this layer :
- jSerialComm : Communicates with the Arduino Mega using the Serial connection
- Efficient Java Matrix Library (ejml) : Matrix multiplications and other operations
- Quarkus-based :
- Rest-easy-Reactive-Jackson : Serialization of objects and Reactive endpoints
- Websocket : Communication with client using websockets
- Mongo DB with Panache : Stores objects (animations) in Mongo Database with the Panache abstraction layer
Docker Compose is used to set up the services of this project (server and database) using the docker-compose.yml file.
Docker-compose can be installed on Windows
easily with Chocolatey, adding the C:\ProgramData\chocolatey\lib path to the Path System
environment variable.
src/java/packagename/
⎿ dto
⎿ exception
⎿ models
⎿ repositories
⎿ resources
⎿ security
⎿ services
⎿ utils
Objects sent by Quarkus as a response to an HTTP request are serialized by the Jackson library. They are decomposed into basic types to the JSON format. In order to facilitate this process and agree with the frontend to a common representation of the objects travelling over the network, we use the DTO (Data Transfer Objects) layer.
As such, each object is re-declared in this layer and made serializable for the Jackson library. The exact same definition of the DTOs can be found on the frontend's side. Only fields interesting to the other side of the network should be specified on this layer, as the rest of them are not relevant and may often constitute abstraction leaks.
This directory holds all the custom exceptions for the application
This is the only directory (along with utils to some extent) that should hold the implementation
details of the model behind your application (also referred as "business logic").
In our case, it holds all the computation for the control of the arm.
Repositories used for persisting objects in the application. In our case, we have a Mongo service running in a docker container
For now, only animations are saved to the database
The resources directory declares all the endpoints reachable by the frontend. Handling
of all types of HTTP requests (GET, POST, ...) is implemented here even though it can
be mostly summed up to forwarding the calls to the services layer.
This directory handles the security logic of the application, which currently isn't much.
For now, it simply checks that a client trying to establish a connection to websocket does so with a valid token that it previously got from an HTTP request to the server.
Everything that isn't really proper to the business logic goes here. That includes things like implementation of mathematical concepts like Vector3D...
The framework chosen to code the frontend of the application is React with a layer of TypeScript on top to enforce types and have a cleaner code with improved auto-completion from the IDE.
The React code also uses the Material UI library to have nice-looking components out of the box.
A description of the principles of the architecture used can be found here
Sources of imprecision
- The metal pieces' insert connecting the motor's axle to the rest of the structure tend to untighten
- The PETG printed piece under the joint labelled
Shoulder_1bends under the weight of the arm
Other remaks :
- The motors must be very slow when acting with an extended arm due to the high torque
Papers that I read fully or just in diagonal in the format (Only most relevant papers read are listed here) :
<Relevance/How much it was used>/5 - Name : [Desciption/Note]
3/5- Design and Implementation of a 6-DOF Intelligent Single-arm : Learn the existence of Denavite-Hartenberg parameters and tables5/5- Solution of Inverse Kinematics for 6R Robot Manipulators With Offset Wrist Based on Geometric Algebra3/5- Introduction to Inverse Kinematics : List of different methods for solving inverse kinematics numerically5/5- Analytical Inverse Kinematic Computation for 7-DOF Redundant Manipulators With Joint Limits and Its Application to Redundancy Resolution : Complete solution for analytical Inverse Kinematics4/5- An Analytical Solution for Inverse Kinematics of 7-DOF Redundant Manipulators with Offsets at Elbow and Wrist : Helped understand the previous paper