SCARA

Description

What is the project?

To develop and prototype a SCARA robot, three main components are required. Mechanical system, Electronic system and firmware. This project focuses more on the electronic system and the firmware development. The mechanical system is pre-made and will not be covered as a part of this project.

​

The controller designed and developed for this project is similar to many standard robot controllers. The controller PCB is designed to hold two microcontrollers on board: Arduino Nano 33 IoT and STM32F401Rex Nucleo 64 Discovery board. The STM32 board is a powerful 32-bit Arm Cortex M4 microcontroller. This will be the central processing board as it will perform in real time, running a Real Time Operating System. The Arduino 33 board is a 32-bit Arm Cortex M0+ microcontroller.

​

A PCB was developed for the SCARA robot controller. The development was done on Altium Designer 2019. PCB consists of a power regulator, Nucleo 64 board, 5 LEDs, MicroSD card reader, 6 pulse and direction connectors and 2 I/O connectors. The SCARA robot controller designed for this project is named ‘Sierra’. Several versions of Sierra were design and only two prototyped. The latest version Sierra v0.2 fixed problems with the first version and on testing worked as designed. 

Since the PCB was developed in a hurry as this project had a hard deadline, a lot of the design is raw. Boards mounted on top of another, large THT components and a general lack of features. The second phase of the SCARA project focuses more on the PCB and aims to develop a more professional board with more features and circuitry to support future software updates.
 

Cabinet wiring is a critical element of industrial robot system. It allows users and operators to move the robot system easier and keeps the electronics secure. Every cabinet is a metal box with an IP rating that guarantees that the electronics inside it will be secure under harsh (high temperatures, high humidity) environment conditions. It takes mains input and delivers power and control signals directly to motors mounted on the robot. All sensors and peripheral are wired inside the cabinet. An emergency button and indicator light is always present for safety and error indication to an operator. Cabinets that are rated for their safety have hard wired relays that cut off the power supply when the emergency is pressed. This guarantees that the machine will power down and no piece of software is a part of the safety loop.

The firmware for the Nucleo 64 Discovery board was developed using the Visual Studio Community Edition 2019 (VS2019) with a cross-platform development API Visual GDB and Visual Micro.
The firmware development started with a FreeRTOS example code. As the firmware did not compile, several external libraries had to be included for the compiler to access all the necessary device libraries. The RTOS has a configuration file necessary for configuring the operating system. The STM32 board was initially running a 16MHz, later updated to 64MHz after soldering an external crystal (8MHz) and configuring the clock. This controller can run at a maximum of 84MHz.

The Operating System was configured to operate pre-emptively. In computing, pre-emption means that a higher priority task controls the processor followed by other tasks operating at lower priority. A faster tick rate results in smoother motion as position are generate at a higher resolution. Each process running on the OS will be allocated a stack size. If the process exceeds its stack allocation, the RTOS kills the task and the doesn’t run again. If the sum of stack size of all the tasks exceeds the heap size, then the operating system throws a fault and stops working.

​

Four main tasks were required for this project: Robot Kernel, I/O handler, Communications task and a standard program handler task.
The Robot kernel actively  controls the robot. It runs a custom robot library designed for this project. Trajectory planning, Motion planning and Kinematics are the main parts of the kernel task. The task starts with homing the robot. “In robotics, homing can be defined as that behaviour, which enables a robot to return to its initial (home) position” . The robot prototyped used in this project has stepper motors with no encoders and limit switches. The program moves each robot until it hits one of its limit switches.

​

Moves can be loaded by calling three types of functions, MOVEL, MOVEJ and MOVEC.  MOVEL loads a linear move to an absolute trajectory point specified in the function call. The end effector travels linearly, utilizing inverse kinematics to calculate joint positions.

MOVEL loads a linear move to an absolute trajectory point specified in the function call. The end effector travels linearly, utilizing inverse kinematics to calculate joint positions.
MOVEJ loads a  joint move to an absolute joint target.

MOVEC loads a circular move with two absolute end effector target positions, one on the end point of the circle and the other mid-point.

​

​

The I/O handler task reads and controls the I/O on board the controller. This task reads every input and stores its state in a structure. Other tasks can access this value. For example, forward and inverse limit switches. The I/O handler task reads the state of this input and stores it in the axis reverse and forward limit switch value parameter. The robot kernel checks this parameter while moving the axis to ensure that the axis stops moving if it hits a limit.

Using an SD Card on the controller is a challenging task due to several reasons. The SPI communication is difficult to setup without and testing equipment(like an oscilloscope). The controller needs to follow a file system for the SD card. Several Libraries are designed by the community for SD card file system. These libraries consume a large amount of memory and require a lot of modifying as they are generated for generic microcontrollers.

​

The role of the Arduino 33 is to add IIoT functionality to the controller. The Arduino can connect to the internet via Wi-Fi. For this project the ThingSpeak [23] API is used as a gateway to upload, processing and receiving data to and from the internet. It allows uploading and downloading data securely and reliably. The API also includes MATLAB and HTTP integration, meaning a MATLAB script can read and upload data to the cloud.

The developed firmware, uploads data to the cloud. This is tested by uploading temperature sensor data (collected from the onboard temperature sensor) to the cloud. This allows remote monitoring of the cabinet’s internal temperature. The firmware also reads commands loaded into the API. This is used to develop a MATLAB application that loads jog commands and displays position data. This acts as a remote Human Machine interface to control the robot remotely.