After testing the platform with the universal joints, we decided to revert to using the magnetic joints again as the universal joints had too much play within the joint connections, causing the platform to wobble about even while stationary. The best solution would have been to buy better universal joints but as we are days away from the presentation we can only fall back on the magnetic joints.

The application of the 6-DOF platform we intend to present is using the platform to do a 360-degree microscope inspection of a component on a PCB. Current microscope inspection can only scan from a top-down view, our platform would allow the user to inspect the sides of the component for damage such as broken solder joints. The demonstration shows the high accuracy, precision, and range of motion of the platform in order for it to be able to perform such an inspection.

We also managed to adapt our 6-DOF software and hardware to show a 3-DOF system even though it is very buggy as it is in its early stages of development.

3-DOF proof of concept

6-DOF platform V2 with universal joint rods

Microscope inspection (6-DOF application)

Sleep deprivation claims another victim

We finish the 3rd guide plate prototype and start to design the guidance plate attachments that will hold the actuators in place. However, it seems that while we gave much thought to the engineering aspect of the parts, we did not put as much thought into their aesthetics. The colour combination of the parts would probably give any ADM student an aneurism on sight.

Guidance plate prototype v3 and attachments (Discount BlackPink Edition)

Dyllon showing his support for the BlackPink theme

After redesigning the attachments and printing them in a better colour, we attached the actuators to the guidance plate base plate. All that’s left is to attach the platform to complete the assembly of 6-DOF platform V2 for testing.

On the software front, issues with live input continue due to state issues. We need to somehow capture and store the platform’s state when a change in input is detected in order to path the next move. Also, the higher number of commands issued in live input would lead to buffer issues as well. Right now, we are looking into using the built-in G-code commands in Marlin to update the app where the platform is.

In other news, the final presentation for our project is next week. This means we will also have to start preparing for our project application and slides. Hopefully, we won’t lose too much sleep because of this. (Spoiler: we did)

Attachments V2

Actuators installed with guidance and base plate

 

Assembly Timelapses

Using a mitre saw to modify the aluminium profiles for alternative DOF varients

We started our designing and prototyping for our revised 6-DOF platform. The main objective of this design is to increase ease of installation, eliminate as much error as possible, and increasing the load-bearing capabilities of the platform.

In order to achieve these, we opted to use universal joints as opposed to magnetic joints, redesigned the base adapter plate, and added a guide plate. 

We expect the 6-DOF platform V2 to be robust enough to be our final version and meet our requirements of accuracy and load capabilities.

On the software front, the precision of the output values has improved as we switched from tensor flow to pure typescript for our calculations. Tensor flow has inherent precision issues but if we were to use the platform for applications involving machine learning we have the option to switch back.

We are also starting to experience problems we believe are due to buffer constraints as seen with the python code. It seems that our program is sending commands too quickly and we will have to slow it down to allow smooth movement.

Guidance plate prototype V2 “modification”

Guidance Plate V2 “installed”

 

This week we focused on the 4-legged configuration. This configuration does not seem to have the same stability issues as the 3 legged configurations. Due to the lower complexity and fewer issues, we decide to focus on the 4-legged configuration first.  We also plan to fabricate a universal platform that can be used across all our configurations.

We received the universal ball joints we ordered a few weeks back and were met with a  pleasant surprise. The joints are able to be adjusted such that one end can act as a rotational joint. This means we can use the same joints for the hexapod as well as the tripod.

Development of the application has progressed and we now have a live input mode which was not possible in the python command-line program. The user can now input values the hexapod would respond in real-time. Further optimization is needed to reduce the latency though.

Universal joint + rod

Quadrapod base adapters

Quadrapod mounting configuration

Universal joint that can act as rotational joint

Live input demonstration

The COVID-19 situation in Singapore has suddenly taken a turn for the worse and our access to the lab has been limited due to safety guidelines. This would hinder our progress on the platform and is also the reason why the posts are becoming shorter. 

This week’s progress was mainly improvements to the application and development of the 3-legged platform configuration. We printed out a platform and tried testing the 3-legged configuration on our existing 6-legged set-up to test its capabilities. Unfortunately, the 3-legged configuration cannot be set up using the hexapod set-up and will fall apart on its own. We suspect the problem lies in the actuator-rod joint baing a spherical joint. We think changing this joint to a rotational joint would allow the 3-legged configuration to work. Further testing and development of the parts for the tripod setup will be needed.

Tripod setup

Spherical joints causing the platform to be unstable

 

The current configuration of the platform still has some errors which we suspect have to do with the hardware mounting of the platform. The accumulation of these errors results in a substantial error in our movement overall (~15mm in the worst-case scenario). We plan to re-evaluate the design of the mounting system and reprint the parts again with added improvements to structural integrity and ease of installation. We are also starting to explore different configurations of the platform which vary based on the leg height and number of legs.

These new parts will also take into account the change of joints to the universal ball joints. We feel that the change to a rigid universal joint would allow us to have more accurate movements and higher load-bearing capabilities which are much needed.

In the realm of the software side, the application for our hexapod has progressed. The app can now directly control the hexapod through a serial connection. The app also allows seamless serial connection to the Arduino which is a step-up from the python code which needed the COM port to be hardcoded prior to launching. The application will steadily improve in its optimization and features over the next few weeks. The next few features we intend to implement include a configuration page, homing and initialization functions, and presets.

A new movement script for the hexapod has also been made to demonstrate its rotational capabilities.

The rotation movement script in action

 

Most of the time this week was spent optimizing code and writing a sequence of motions for the platform to display its capabilities as well as preparing for an update presentation on the 9th.

A dynamic slicing number generator was added to the code which should smooth out our motions. We also managed to add some delay to the sending of data to the Arduino to prevent serial buffer overflow. 

Some improvements in the hardware section include the 3rd actuator platform adapter that now has a variable height function. The ball joints are also able to be friction fit into the adapters after lowering the tolerances.

The 3rd platform prototype is completed but the tolerances are still not small enough. This could be due to print inaccuracy as the tolerance given was the same as the actuator platform adapters.

The 2nd guide prototype has finished printing and prevents any play in the actuators while leaving just enough space for the actuators to move freely without restriction.

We are exploring alternatives to the magnetic ball joints to increase load capacity and reliability. Currently, universal joints are what we have in mind but this would cost quite a bit and require the redesign and fabrication of some of our existing parts.

One of the sequences we programmed

The 2nd prototype of the actuator base adapter mount has finished printing. The reinforced design of this prototype helps in its structural integrity and we didn’t face the same issues as the 1st prototype. However, there is still considerable play in the actuators. Further parts have to be designed and printed to reduce the play in the actuators.

The 1st prototype for the limit switch attachment has finished printing. This results in a far more consistent actuation point which makes the homing sequence more accurate.

Due to the inconsistent heights of the aluminum profiles of the actuators, the 2nd actuator platform adaptor has to be able to change its height to offset these inconsistencies.

The first prototype of the actuator guide has finished printing, unfortunately, the tolerance set was too small which restricted the movement of the actuators. An improved design of the guides will have to be reprinted.

We completed the first full assembly of our platform and started our testing. Some issues we faced include unintentional pitch and roll during x and y translation. This issue is exactly the same as what we faced during the creation of the first motion study. Hence we can suspect that this error is due to inaccurate dimensions used in the python code.

Another issue that we experienced was that the platform was operating in the wrong orientation in relation to what we intended to be the front face. A simple rewiring of the motors and limit switches should solve this issue.

Another issue we faced was with the magnetic ball joints. Since the ball joints rely on magnetism to attach the platform to the actuators, the load capacity of the platform is low and in some complex movements, the joints are unable to remain attached.

One software issue we encountered was that the computer was sending instructions faster than what the Arduino could process. This resulted in the serial buffer overflow and instructions would be lost and cause inaccurate movements. We will have to introduce some delay to the sending of instructions to solve this issue.

In order for our movements to be precise, large movements have to be sliced into smaller movements chained together. Currently, the logic behind the slicing is flawed and needs to be changed to a more dynamic system where the number of slices is based on the magnitude of movement. This would ensure consistent movement per slice which would smooth the movements of the platform.

Software restrictions on the maximum range of motion of the platform also have to be set in order to stop movements from causing the platform to disconnect from the joints.

Some software features such as simultaneous homing, emergency stop and pausing movements have been implemented by modifying the existing Marlin source code.

Preparation of the python code for deployment to the GUI app also has to be completed soon.

2nd prototype of actuator base mounting adapter

Optical breadboard standoffs

 

1st assembly of the Stewart platform

 

Movement testing shows unintended roll and pitch during x and y translation and yaw rotation

 

A multitude of our parts has been printed/arrived from China!!!

Firstly, our belt-driven actuators arrived. Some potential issues we identified are the lack of a belt tensioner as well as the gantry plate being attached too tight to the aluminum profile, causing the movement to be uneven. 

Secondly, our first prototype of the actuator base adapter mount has finished printing, some issues we discovered after testing include a very cumbersome installation process and weak spots in its structural integrity when a lateral force is applied. Our second prototype of this adapter will have to be reinforced as well as implement a simpler way of installing it to the linear actuators.

Thirdly, the optical breadboard arrived, we quickly designed some standoffs to be mounted with foam to be attached to the optical breadboard. The optical breadboard seems well made and attaches well to the base mounting adapters we previously made.

Fourth, the 2nd prototype of the platform plate finished printing. An issue we failed to identify previously in our first prototype is also present in this prototype. The holes we designed to place the ball joint attachments have too much tolerance and require double-sided tape in order to stick the joints to the plate. This results in uneven positioning of the ball joints which would lead to less precise motion of the platform. Our 3rd platform plate prototype will need to have smaller tolerances in order to allow us to friction for the ball joint attachments for more precise movements.

Fifth, the 1st prototype of our actuator platform adapter has been printed, a similar issue to the platform plate where the tolerance of the holes for the ball joint is too large is present. We will have to address this issue in the next revision of this part.

Finally, the 1st prototype or about fixed rods have been printed. However, due to print issues, the rods all have marginally different lengths which will contribute to the inaccurate movement. Thus, these rods will have to be re-printed eventually.

In regards to the conversion of inputs to actuator lengths, we decided to use python to run the script to implement the math of the platform. Currently, the code is unoptimized and buggy, and lacks many features such as homing, direct input, emergency stop, and start/stop sequences.

The coding team has to modify the existing Marlin code in order to implement these features. Simultaneous homing is one such feature that is not available in Marlin at all and will have to be coded into the source code of Marlin.

The hardware team installed limit switches to allow the actuators to home, however, the actuation points of the limit switches are not consistent, resulting in inaccurate homing. A part has to be designed and fabricated to be attached to the gantry plate to ensure the actuators home accurately.

An updated and improved stable motion study that uses belt actuators has been completed by the hardware team, this will help us to model the other parts needed to optimize the movement of the platform.

A simple GUI application using typescript is currently in development, this will serve as the interface for our final platform. We intend for his application to be an all-in-one package that handles serial port connections, streaming data, our math logic, and interpreting inputs from the user.

1st prototypes of actuator platform adapter

1st prototype of actuator mounting base adapter

1st prototype of actuator  base mounting adapter with actuator attached

Hexapod GUI

Revised motion study

 

2nd platform prototype

The linear actuator purchased in week 3 arrived and we tested its capabilities. Unfortunately, the specifications listed on its product page do not match its actual performance. The listed speed of the actuator was 30 mm/s while the measured speed was closer to 15mm/s. Additionally, due to the lead screw design of the linear actuator, a backlash error is present which compromises the precision of the position of the platform. Due to this, we decide to choose belt-driven linear actuators instead to run our platform.

While trying to use Marlin 2.0 as the firmware for our platform, we realized that Marlin 2.0 does not natively support 6 stepper axes, this results in a lack of support for homing and other features for the unsupported axes. Hence, the coding team needed to use a prerelease version of Marlin in order to implement 6 stepper axes support. After building and uploading this version of Marlin to the Arduino, we tested the motor movements using Pronterface as a host to see if stepper motors worked properly. Unfortunately, this was not the case as the resultant movements of the stepper motors were glitchy and stable. Further optimization of the code has to be done before testing actual linear actuators. A solution to convert inputs into actuator lengths and streaming to Marlin is also needed to be coded. 

Due to the hexagonal nature of the orientation of the actuators, attaching them to the uniformly spaced breadboard requires individual custom parts for attachment. The hardware team has to design and fabricate this part while leaving very little play to ensure the precision of the platform is not compromised.

The Arduino Ramps 1.4 only natively supports 5 stepper drivers on the board, hence an expansion board has to be purchased and connected in order for all 6 stepper drivers to be run off the same Arduino.

The research team has calculated that the range of motion for 150mm base radius and 100mm platform radius is X, Y: 100mm, pitch, roll, yaw: 45 degrees. This range of motion is good to hear as it far exceeds our requirements for the applications we intend to use the platform for. Nevertheless, these values are theoretical and the actual range of motion should be considerably less especially with the load. 

The research team is also re-classified into the coding team as their focus has almost shifted entirely into creating an interface and implementing coding logic with the mathematical equations needed. 

A simple Matlab GUI was created by the coding team, linking the mathematical equations to the GUI application and implementing event listeners for all of the components are a work in progress and are expected to take a while to fully complete. This is partially due to less than ideal documentation of Matlab which slows down the development of the code considerably. This progress is in vain though as we realized that in order for our platform to work well, synchronous input will be required and Matlab does not support this feature. We decided to abandon working on Matlab and C++ and use widely available firmware such as Simtools, Mach 3, and Marlin as these software readily support synchronous input.

matlab begone

The issues discovered previously regarding rod lengths changing have been rectified. The motion study is now stable and without error.

The 1st platform plate prototype has finished 3D printing, however, due to print issues, one of the edges of the platform is deformed. This deformity does not seem to affect usability and only affects the aesthetic appearance of the platform.

The optical breadboard was quoted to be $400 from the mechanical workshop in SPMS. As the price on Aliexpress for the same dimensions is lower, we decided to purchase the optical breadboard online.

The ball joints and rods ordered a week ago have finally arrived. However, the rods received were not threaded, hence we are unable to attach the ball joints to it. We will need to 3D print custom rods to replace the defective rods received.

In regards to electronic components, we decided to use an Arduino Ramps 1.4 as the controller and TMC2209 as motor drivers.

MatLab GUI

Rod and Platform assembled together

Magnetic joint and unthreaded rod

Deformed platform

 

We completed our first set of purchases which include magnetic ball joints and carbon rods. 1 A2 HB60 actuator was also purchased for testing to evaluate whether its specifications can meet our requirements. If the linear actuator is suitable for our use, we intend to purchase more.

The purchases were mainly made on sites such as Aliexpress and typically shipped from China. As a result, the shipping time ranges from a week to up to a month based on the estimate by the website, actual shipping time maybe even longer. In order to ensure we get the parts we need on time and prevent delays in the progress of the project, we should plan our purchases early and prioritize vendors who offer faster shipping first over a vendor who has a slightly lower price but much slower shipping.

The unintended pitch and roll issues of the motion study were partially rectified. After reviewing the mathematics model used in the excel sheet and the model rendered, we found some discrepancies regarding the dimensions of the rods and platform radius. After making some adjustments, most of the unintentional pitch and roll are nullified. The other contributing factor to the pitch and roll issues was found out to be the rod lengths changes during calculation even though they should be fixed in value. The research team will look into this in order to fully rectify the issue.

The research team commenced on converting the mathematical equations into coding logic. Matlab was initially used but we quickly found out some major flaws with the program that could adversely affect the performance of our platform down the line. Though Matlab is great for ease of use regarding math functions and plotting graphs. Its performance pertaining to calculating many commands quickly and streaming data to a device is less than ideal and would introduce a lot of lag and processing time.

Due to the possibility of Matlab being a bottleneck to the performance of our platform, we are exploring other options to process our mathematical equations and commands while we work on Matlab. Tentatively, C++ is an option we are pursuing. The research team is also tasked with finding out the theoretical range of motion given a platform of 150mm base radius and 100mm platform radius.

Regarding the electronics we planned to use, we found out that ESP32 does not work optimally with DM542 drivers. This is because the DM542 motor driver requires 5V logic for its step and direction pins to work and the ESP32 runs on 3.3V pin logic. We will have to source for alternative parts to run our platform.

A feature of our platform that we are exploring is adding modularity to the system. This would allow the legs of the Stewart platform to be placed in non-standard formations and still function. Changing the number of legs of the platform for different applications and different DOF platforms is also possible with the modularity feature. We plan to mount the platform on an optical breadboard to enable the modularity of the platform. In order to procure this optical breadboard, we plan to approach the mechanical lab for a quote before resorting to purchasing online as fabricating it in SPMS would be faster and more customized to our requirements.

The hardware team has also started modeling the parts to be 3D printed such as the platform and rods.

We completed our first set of purchases which include magnetic ball joints and carbon rods. 1 A2 HB60 actuator was also purchased for testing to evaluate whether its specifications can meet our requirements. If the linear actuator is suitable for our use, we intend to purchase more.

The purchases were mainly made on sites such as Aliexpress and typically shipped from China. As a result, the shipping time ranges from a week to up to a month based on the estimate by the website, actual shipping time maybe even longer. In order to ensure we get the parts we need on time and prevent delays in the progress of the project, we should plan our purchases early and prioritize vendors who offer faster shipping first over a vendor who has a slightly lower price but much slower shipping.

The unintended pitch and roll issues of the motion study were partially rectified. After reviewing the mathematics model used in the excel sheet and the model rendered, we found some discrepancies regarding the dimensions of the rods and platform radius. After making some adjustments, most of the unintentional pitch and roll are nullified. The other contributing factor to the pitch and roll issues was found out to be the rod lengths changes during calculation even though they should be fixed in value. The research team will look into this in order to fully rectify the issue.

The research team commenced on converting the mathematical equations into coding logic. Matlab was initially used but we quickly found out some major flaws with the program that could adversely affect the performance of our platform down the line. Though Matlab is great for ease of use regarding math functions and plotting graphs. Its performance pertaining to calculating many commands quickly and streaming data to a device is less than ideal and would introduce a lot of lag and processing time.

Due to the possibility of Matlab being a bottleneck to the performance of our platform, we are exploring other options to process our mathematical equations and commands while we work on Matlab. Tentatively, C++ is an option we are pursuing. The research team is also tasked with finding out the theoretical range of motion given a platform of 150mm base radius and 100mm platform radius.

Regarding the electronics we planned to use, we found out that ESP32 does not work optimally with DM542 drivers. This is because the DM542 motor driver requires 5V logic for its step and direction pins to work and the ESP32 runs on 3.3V pin logic. We will have to source for alternative parts to run our platform.

A feature of our platform that we are exploring is adding modularity to the system. This would allow the legs of the Stewart platform to be placed in non-standard formations and still function. Changing the number of legs of the platform for different applications and different DOF platforms is also possible with the modularity feature. We plan to mount the platform on an optical breadboard to enable the modularity of the platform. In order to procure this optical breadboard, we plan to approach the mechanical lab for a quote before resorting to purchasing online as fabricating it in SPMS would be faster and more customized to our requirements.

The hardware team has also started modeling the parts to be 3D printed such as the platform and rods.

Our Finance IC Keith compiled the costs of the parts we intend to purchase which amount to $1510. The cost of the project is pretty high and we are trying to source alternative parts so that we would have spare budget in order to replace damaged parts or purchase additional ones.

The research group completed an excel sheet draft and a Matlab simulation using the researched math which would take in values of x, y, z, roll, pitch, yaw, and output the actuator lengths required to achieve the pose. 

Some of the challenges faced include conflicting ideas and mathematics in different research papers. Our version of the Stewart-Platform which employs fixed actuators and freely rotating rods is also vastly different from the commonly researched and used version of Stewart-Platforms which use freely moving linear actuators or servo motors. As a result, we had to make some modifications and adapt the equations found in the research papers for our Stewart-Platform. Unfamiliarity with Matlab also made the creation of the simulation difficult.

The hardware group finished its first revision of the Stewart-Platform model and implemented the mathematics researched by the research group into the model to produce a motion study.

The motion study showed that a translation in the x and y direction would result in an unintended roll and pitch of the platform. Further investigation is needed to understand and rectify this issue.

The research team will continue to optimize its mathematics model and develop a way to determine the range of motion of the platform and possible collisions between legs given a configuration of the Stewart-Platform.

In terms of our choice of electronic components and linear actuator, we decided to use the ESP32 as the microcontroller, DM542 as the motor driver, and the A2 HB60 as the linear actuator.

Preparation for the 1st presentation on the 28th of May also has to be completed.

Our Finance IC Keith compiled the costs of the parts we intend to purchase which amount to $1510. The cost of the project is pretty high and we are trying to source alternative parts so that we would have spare budget in order to replace damaged parts or purchase additional ones.

The research group completed an excel sheet draft and a Matlab simulation using the researched math which would take in values of x, y, z, roll, pitch, yaw, and output the actuator lengths required to achieve the pose. 

Some of the challenges faced include conflicting ideas and mathematics in different research papers. Our version of the Stewart-Platform which employs fixed actuators and freely rotating rods is also vastly different from the commonly researched and used version of Stewart-Platforms which use freely moving linear actuators or servo motors. As a result, we had to make some modifications and adapt the equations found in the research papers for our Stewart-Platform. Unfamiliarity with Matlab also made the creation of the simulation difficult.

The hardware group finished its first revision of the Stewart-Platform model and implemented the mathematics researched by the research group into the model to produce a motion study.

The motion study showed that a translation in the x and y direction would result in an unintended roll and pitch of the platform. Further investigation is needed to understand and rectify this issue.

The research team will continue to optimize its mathematics model and develop a way to determine the range of motion of the platform and possible collisions between legs given a configuration of the Stewart-Platform.

In terms of our choice of electronic components and linear actuator, we decided to use the ESP32 as the microcontroller, DM542 as the motor driver, and the A2 HB60 as the linear actuator.

Preparation for the 1st presentation on the 28th of May also has to be completed.

 

Unintended roll and pitch during translation as shown in the motion study

28 May 1st Presentation

A small snapshot of calculations excel sheet

 

We had our first meeting on the 18th and laid the groundwork for the project. Roles for each member were established and an outline of the project plan was drafted. We decided to focus on the precision aspect of our Stewart-Platform and that some applications we would consider to showcase the platform include aligning optic cables and calibrating precision microscopes.

We also decided on the 6-6 version of the Stewart-Platform where each leg would be attached to 6 individual points on the platform.

We split the group into 2 teams, the first team would focus on researching Stewart-platform mechanics and the math behind the motion. We intend to use MatLab to compute these calculations as it is designed to handle complex matrix equations such as the Stewart-Platform equations. The second group would focus on modeling the Stewart-Platform using Solidworks in order to conduct a motion study we could use.

The research team quickly found that inverse kinematics was the core principle behind the motion of the Stewart-Platform. The calculation of the Stewart-Platform starts from establishing a final position of the platform and deducing the length of the actuators needed to get the platform to that position. Coordinates of the joint positions and the center of the platform would be the reference points needed to make this deduction.

 A summary of the core equations involved is shown below which include the rotation matrix as well as vector equations that resolve for the magnitude of actuator length for each platform leg.

 

 

A consolidated and simplified version of the interesting and fun 🔪😂 equations encountered

Preliminary Timeline:

Outline of timeline for the project (May) 

Initial research 

Calculation of geometry

Purchase of components 

 

Outline of timeline for the project (June) 

Motion study of mechanism in SolidWorks 

Design of parts on SolidWorks (for 3D printing) 

3D printing of platform, platform rods, secondary platform, adapters for holding the linear actuators in place 

Purchase of magnetic joints, linear actuators, controller board, motor drivers 

Familiarize with coding software (e.g. Mach 3, Codesys, Raspberry Pi) 

Begin assembly of the 6DOF platform 

 

Outline of timeline for the project (July) 

Coding 

Troubleshooting 

Prepare presentation slides 

 

18 May 1st Meeting