SCARA arm report

SCARA Arm Report - ENGR110 2016

SCARAArmReport

ENGR110,2016T2

Name:Tom Brown

StudentNumber: 300371619

Labday&time:Thursdays at 11:00am – 1:00pm

GroupMembers: Tomas Brown (Author of this report)

Jacob Woods

Lutfi Jamaluddin

Stuart Hood

Abstract

This report will discuss the progress and results of a software model designed for a hardware system, specifically a SCARA robotic arm. The main focus of the group working on this particular project is to create working control software for a SCARA robotic arm that has been designed to draw on a piece of paper. There are multiple drawings that have been specified by the team behind the creation of this challenge, these include: a straight horizontal line across the page, a square with sides 40mm apart from each other, a circle with a radius of 25mm, the string ‘SKYNET’, a given picture of a snowman and finally a given photo of the course coordinator. These are some of the drawings that the SCARA arm will be assessed on and a representation has been included of each drawing below in Fig1.0. There are also tasks that it will have to be able to perform that aren’t drawings. The SCARA arm will also be assessed on the quality of the equations behind the software, its ability to be able to find extreme positions (positions that are out of reach of the arm), whether there are checks in the program that avoid singularity locations and finally the implementation of a button in the Java GUI that allows a text file to be transferred to the arm through a Raspberry Pi. The aim of the project is to put the students involved in a practical and real life engineering situation, working together as a group to put the knowledge of hardware and software engineering students into one successful product. A marking scheme has been included below in Fig1.1 to show the weighting of each of the tasks that will count towards the robotic grade of the challenge.

Tomas Brown ! of !1 10



Fig 1.1

SKYNETCompletion

Core

Challenge

Fig 1.0


Introduction

Scope

The SCARA arm project’s purpose is to test the students knowledge of the aspects of ENGR110 that has been taught this year and to also introduce the students into group projects and teach them about project management. The project itself mostly covers the software engineers role in a team of engineers working on a project, the hardware had already been created and tested so the only task that was needed was to find the algorithms and equations that would get the hardware working and then input these equations into a skeleton model of a working software system and finally tweak the program until the robotic arm acts as it is asked to on a recurring basis. The project will test each students ability to work together as a team in a real life environment, designing, creating and evaluating a project with a set aim to achieve. This is an introduction into the world of Engineering and many more projects to come during students study and future careers, the project will test all areas of Engineering including programming languages, problem solving, mathematics and logic, but will first test the students ability to work together as a team with the pressure of a deadline that they must meet. Motivation

The motivation behind the SARA arm project is to give each and every student behind the ENGR110 course a taste of what the real world of engineering holds for them. Students will be asked to find groups by themselves of no more than three and create a solution to a given problem, they are given small amounts of help from tutors and lab coordinators but will mostly be working in their groups to simulate a real life situation. Most of the assignments and projects the students are given are purely based around a single form of engineering whether it be a mathematical, software or a hardware based assignment, this assignment is designed to combine all three and try to move away from a theoretical situation into a practical working environment. The main motive is to put the student out of their comfort zone, give them an understanding of what is expected of them in the future and test their ability to manage a group project.

Aim

The aim of the students behind each group is, to the best of their ability, create a working control system for the SCARA arm robot supplied by Victoria University. If a particular group is successful, their working SCARA arm will be able to complete all of the tasks allocated by the challenge by the allotted due date. There are two parts to the assignment that the group will be marked on, first is the success of the robotic arm and the software model, a marking scheme has been supplied above in Fig1.1 to show where each of the marks come from for this section. The aim of each student is to have their software model complete every single task shown in the marking scheme, this is a challenging but achievable goal.



Objective

The objectives for the group in the SCARA arm assignment are:

- Create a realistic dated plan for the groups progress on the assignment from the start to finish product of the software model so the group can stick to a strict deadline and meet each requirement by each end of the week. The rest of the objectives are shown in a dated plan format.

By the 12th of September

- Research the theory behind the SCARA arm and what the necessary direct and inverse kinematic equations for the software control system are.


- Derive the necessary direct and inverse kinematic equations for the software control system.


- Implement these equations into the skeleton software model that has been provided.

By the 22nd of September

- Test that these equations work with the skeleton software and finalise the java simulation to behave as required defined by the lab script.


- Load the code from the skeleton software onto a SCARA arm and get the arm to draw required drawings, string and pictures.

Benefits

The two types of benefits are shown below:

Short term benefits - are that the students will be doing tasks that are not just theory, they are working on a group practical project as they would in a professional engineering environment. They will learn crucial skills that will transfer directly into the next semester’s courses and assignments. Also instead of working in an exam environment the students are able to show their capabilities not just on memory and information retention they have a chance to show their abilities in an environment that is not pressured and can be completed to a standard that they are happy with.

Long term benefits - include the fact that wherever in the engineering field the student may be taking their studies, they will take a greater understanding of what is expected of them in the future. Every student will have to put in a certain amount of work that they have learnt in the past semester of study and will be able to practice how to create a fluid and collaborative team that can stick to a strict timeline and get tasks done on time to a high standard.



Background

A main component that will process the information for the SCARA arm robot will be a Raspberry Pi, the Raspberry Pi can perform almost any task that a household computer can do but it is the size of a credit card and only a fraction of the price. The Raspberry Pi creates a very simple platform which makes it easy to use for a user with any range of experience in computers, it accepts many languages such as C-script, Java, etc. The Raspberry Pi also has the ability of connecting to a range of input and output devices that allow it to interact with users and conditions in the environment around it, such as a SCARA arm. A picture of a Raspberry Pi is shown below in Fig 2.0

The other component of the hardware is the SCARA arm itself, made up of two motors and five joints all converging at one pen that is controlled by the system that will be connected up to a java simulation of the robot. The SCARA arm idea is used in many situations such as a manufacturing line where the manufacturing robot will need to know exactly where the arm is and needs to go. This is all done using software and algorithms that allow the system to be in control of the arms movements in a precise and efficient way. A diagram of this is shown below in Fig 2.1.

Method

Direct and Inverse Kinematic Equations

The first step in the long process ahead was to find all of the equations needed to describe the motion of the arms, these ‘equations of motions’ can be split into two categories;

- direct kinematic equations which, given known positions of the motors and angles of rotation, predict the position of the pen

- inverse kinematic equations which, given the angle of one motor and position of the pen, produce the necessary angle on the other motor in order to achieve this position.


Fig 2.0 Fig 2.1

Motor 1 Motor 2

Joint 1 Joint 2

Pen


List of direct kinematic equations that have been derived using mathematics and the descriptions of what is being calculated:

- xJ2 = (xm2 + (xt-xm2)/2) + h2*cos(π/2 - atan2(ym2 - yt, xt - xm2))

- xJ2 is the x coordinate for the right hand joint between the pen and the motor.

- yJ2 = (ym2 + (yt-ym2)/2) + h2*sin(π/2 - atan2(ym2 - yt, xt - xm2))

- yJ2 is the y coordinate for the right hand joint between the pen and the motor.

- yA = yj1 + 0.5*(yj2 - yj1)

- yA is the y coordinate of the mid point on the line between joints 1 and 2

- H =√(r2 - d2)

- H is the length of the line perpendicular to the line between joints 1 and 2 at point A, this connects to the point where the pen is located.

- xT2 = xa - h*cos(atan2((yj1-yj2), (xj2-xj1))-π/2)

- xT2 is the x coordinate of the location of the pen or tool.

- yT2 = ya - h*sin(atan2((yj1-yj2), (xj2-xj1))-π/2)

- yT2 is the y coordinate of the location of the pen or tool.

List of inverse kinematic equations that have been derived using mathematics and the descriptions of what is being calculated:

- xJ2 = (xm2 + (xt-xm2)/2) + h2*cos(π/2 - atan2(ym2 - yt, xt - xm2))

- The x coordinate of the right hand mid joint, there are two ways to calculate this coordinate as there are always two ways the arm can be positioned, this was chosen as the final algorithm as it gave the best results.

- yJ2 = (ym2 + (yt-ym2)/2) + h2*sin(π/2 - atan2(ym2 - yt, xt - xm2))

- The y coordinate of the left hand mid joint, there are two ways to calculate this coordinate as there are always two ways the arm can be positioned, this was chosen as the final algorithm as it gave the best results.

Implementation of the kinematic Equations into Java Simulation

The implementation of these equations into the skeleton code provided is the next crucial step for the simulation to work. The spaces in the skeleton code were for the equations with variable names describing which equation to use, the program complied quickly but didn’t function well until after some debugging and figuring out the parts of the code that were causing faults. Eventually the program was simulating a SCARA arm, much alike the simulation provided by the lab script.



Avoiding Singularity Positions

A singularity position is a position that the joints and arms could be in, where it would create further movement impossible because the joints are opposing each other. The SCARA arm used to find the exact position where an arm singularity would occur, the distance between each of the joints was measured and found to be 350mm. The code below in Fig 3.0 shows how this is prevented, a simple calculation found the distance between each of the joints at every moment the joints moved, if this measurement was over 250mm the user would get a warning message that it is close to a singularity position. If it was moved closer over 300mm apart then the arm would be inside the danger zone which was called an ‘invalid_state’, this was a boolean variable in the simulation where the arm would not draw and the user would know not to draw values there.

Purpose of the Software Model

The purpose of the Java Simulation that is now functional is that it creates a platform where the student can test the code that they have come up with from the equations and the skeleton code and keep on figuring out what parts are wrong or correct and change the incorrect code without having to test it on the arm each time. The process from taking the drawings into a file of pulses and then transferring this file onto the Raspberry Pi and loading it onto the arm was far too long to be testing and debugging the code without a GUI to see what was happening. It also created a way for students to see how the arm worked before they started using it, as most of the students had never used a SCARA arm it was a great learning tool to picture what was supposed to happen when everything went right.

Using the java simulation and the SCARA arm to draw pictures

To make the SCARA arm work like the simulation was working the movements of the simulated arms were calculated into pulses and saved into a file on the teams Github, linked here “https://github.com/Abyss-Wanderer/ENGR110_SCARA” these files were then saved onto the Raspberry Pi and run through the terminal executed onto the SCARA arm. The pictures ran wrong at first but after some time was spent on calibrating and debugging the pulse finding algorithm the arm would act exactly like the simulation did.


Fig 30.

https://github.com/Abyss-Wanderer/ENGR110_SCARA


Results

Results of core hardware tasks

The SCARA arm robots performance for core tasks has been tabulated below:

Performance of Challenge and Completion tasks

The SCARA arm robots performance for completion and challenge tasks has been tabulated below:

Simulations VS Drawings


Drawing the word skynet was a Completion task worth 10%, the result from the arm was readable but the pen wasn’t lifting up the whole time and we ended up with linked writing and found a bug after marking that fixed this problem. The mark

received was 7%

Achieved Mark Possible Mark Total

Completion

Implement a button in the Java GUI that transfers a text file to the arm 0% 5% 53%

Write the word: Skynet using the arm 7% 10% 60%

Challenge

Draw the unicode snowman 0% 10% 70%

Draw a picture of Elf as found on assignment web-page 0% 10% 70%

Drawing a circle was a Core task worth 10%, the group received a 9% mark, it was a good

result the only setback was the unclosed part of the circle where there was a gap between the

two ends.

Achieved Mark Possible Mark Total

Core

Complete derivation of direct kinematic equations for arm 5% 5% 5%

Complete derivation of inverse kinematic equations for arm 5% 5% 10%

Implement kinematic equations for arm in Java model of arm 10% 10% 20%

Estimate reach zone for given arm dimensions and motor positions 5% 5% 25%

Draw a straight horizontal line across the page 10% 10% 35%

Draw a square with sides 40mm in length 9% 10% 44%

Draw a circle with a diameter of 50mm 9% 10% 43%

Implement checks in code that avoids singularity locations 10% 10% 53%


Results Conclusion

The marking session for the hardware/software part of the SCARA arm challenge resulted in a 70/100 mark or 70% grade for 10% of the overall grade, the other 10% comes from this report. The core drawings of a line, square and circle were all very good, only losing 1% mark on the square and circle but the line was perfect, it was the completion drawing of the word ‘SKYNET’ that lost 3% and the 20% that was lost in the challenge that created the biggest dent in the overall mark. The other 5% that was lost was on the button that should have been implemented to send the code straight from the Java Simulation to the Raspberry Pi which was left out due to time shortage.

Discussion

Communication was the main let down from the very start of the challenge for the group, the first week wasn’t very profitable in terms of progress but after some organising and leadership the group set in and started working very well together. Extra sessions were done to make sure that the group got back on track with the timeline set and soon enough serious progress was being made. The shapes drawn were to a high standard but it was the string where the group was let down, next time to improve results a more strict timeline would be set and better communication from the get go would be crucial. There were still a few bugs in the program at the end of the marking session and they seriously messed with the programs smooth running, but it was not only the smooth running of the program that lost marks. There simply wasn’t enough time to find out how to draw the snowman and picture of Elf which if time had been allocated better could have been completed as the group was on track to a very successful program. The team however did do very well finding the equations and inputting them into the skeleton program as the simulation was up and running very fast. Maths was a strong point of the team as the PWM save file process was done quickly as well. The only other setback other than time management that put the group behind was the ignorance of the use of a SCARA arm and the Raspberry Pi. Tomas Brown ! of !9 10

The horizontal line was another core task that took up 10% of the overall mark, this line

achieved full marks as the SCARA arm had good control over the pen throughout the whole

drawing.

A square was a core task as well and the group ended up getting 9% out of a possible 10%, the 1% was lost on the final corner where the ends aren't exactly perpendicular and don't stop on

the same spot, overall a good result.


Conclusion

The SCARA arm was much more difficult to master but a lot less intimidating than once thought, it has a simple idea behind it which only uses simple mathematics and trigonometry which by the end was understood by the whole group. The simple idea is easy to understand but taking it further and introducing line detection and tracing from other pictures as a bit too far for the group. It was smart to focus on the easy tasks first and was the correct course of action as a high grade was still achieved where as if the higher completion and challenge tasks were attempted before the core was sorted out there would have been much more issues and luck would not have been on the groups side in the end when we finally sorted out the simple tasks. The idea to hardcode all of the shapes took a long time to program and debug but it saved a lot of stress in the end because it was easy to show the program to the marker and easy to make the same file every time a new simulation was to be made, and also to test the shapes small changes could be made and reviewed instead of starting a whole new shape again drawing by free hand.

References

O’Conner,L.2016,Reportwri5ngforENGR101,VictoriaUniversityofWellington,Wellington.

ENGR110T22016:Scheduleoflectures,tutorials,assignments,tests,andholidays.2016,VictoriaUniversityOfWellington,Wellington.Viewed5October2016,hGp://ecs.victoria.ac.nz/foswiki/pub/Courses/ENGR110_2016T2/LectureSchedule

ENGR110ControlSystems:ARobo5cArmReport2016,VictoriaUniversityOfWellington,Wellington.Viewed5October2016,hGp://ecs.victoria.ac.nz/foswiki/pub/Courses/ENGR110_2016T2/Assignments/RobotArm.pdf


http://ecs.victoria.ac.nz/foswiki/pub/Courses/ENGR110_2016T2/LectureSchedule

http://ecs.victoria.ac.nz/foswiki/pub/Courses/ENGR110_2016T2/Assignments/RobotArm.pdf

Documents

SCARA arm report