Mechatronics on Campus

A Mechatronic and Medical Marvel: Heavy Ions Curing Cancer at GSI

The Gesellschaft für Schwerionenforschung mbH (GSI), or Association for Heavy Ion Research, is a research facility where scientific researchers work with heavy ions for a wide range of experiments to explore the structure of matter. GSI is a particle accelerator facility where ions are accelerated up to 90% the speed of light.

Of the accomplishments at GSI, atoms of atomic number 107 through 112 were discovered at GSI: Bohrium, Hassium, Meitnerium, Darmstadtium, Roentgenium and Ununbium. Another major accomplishment is the use of heavy ions to treat cancer.

In the United States, ionic cancer treatment is primarily done by bombarding protons at a patient’s tumor. The heavy ion accelerator, as the name suggests, accelerates muclei of heavier elements, and for cancer treatment, carbon. These carbon nuclei are particularly adept at destroying tissue, yet are able to destroy tissue at a point. The diagram below shows the higher energy released from carbon ions.

When carbon atoms penetrate the patient’s skull, they pass through the brain tissue, but when they reach a specified depth, they radiate the tissue. This means that the bone, tissue, and everything between the environment and the patient’s tumor, is virtually untouched, but the tumor is destroyed. This specialized radiation beam is created in the huge GSI complex.

Although the carbon nuclei treatment has obvious advantages, including damaging less good tissue and destroying tumors more effectively than using a proton beam, the technique is not used in the US. A problem is that creating a heavy ion beam is more diffucult than creating a proton beam and the only current place for treatment is at GSI, near Darmstadt, Germany. Patients often bike to their daily painless radiation treatment that lasts normally a bit less than a month.

Currently a smaller heavy ion beam still capable of penetrating any depth within a human body is being built in Frankfurt, Germany as a sole medical facility. Other centers are planned through-out Europe to precision treat cancerous tumors.

European funding for public facilities and research project has been surging in recent years. This is particularly evident in higher education, where Germany has funded a total 1.9 billion Euros known as the “excellence initiative” where young scientists and PhD students receive one million Euros each at certain Universities.

The above photos (click to enlarge) from left to right: (1) The control room at GSI oversees the UNILAC linear accelerator and synchrotron. (2) The yellow section is the acceleration phase of the synchrotron where millions of volts accelerate ions. (3) The red section is the steering phase where the ions are precisely turned using very strong magnetic fields produced by the huge wire coils. (4) A research sensor array for detecting scattered ions and atoms.

Error? Fixing Code and Embedded Hardware the Easy Way

You’ve worked all day on implementing a complicated function and it’s time to see whether it works. You compile the C++ code and program the memory on the microcontroller.

Dead. Nothing happens.

What to do? First, obviously look for any compiler warnings, such as infinite loops, etc., but if everything looks good, where do you turn to?

In mechatronics there are often many different systems working together and each possibly has its own computer software, hardware programmer, clock speed, voltage input and much more variations. How do you keep all of this straight? Data sheets are vital to have easily accessible and often having both a digital and hard copy is a good idea. The hard copy is good so you can not only rest your eyes, but also to make it easier to type on the computer, e.g. while looking at register descriptions. Digital copies of data sheets in PDF format are wonderful because you can search a document or an entire folder of documents for a search string.

But who wants to always read through data sheets to find what voltage to plug a motor into?

Doing things by memory can be costly and even dangerous — it’s a huge source of human error. You need a central place with condensed information, such as a motor and voltage chart, or a header pin diagram with descriptions, with easy to understand notation in your own style.

A detailed notebook would be essential to help solve these problems.

I’ve seen a researcher too often using a legal pad to write down e.g. resistor values or baud rate calculations. It may be possible to save legal pad sheets of paper, but it’s not natural to save a pile of ragged-topped sheets of paper that are likely curled or otherwise unkempt. When a change cascades through the system, such as an increased baud rate, having the previous calculations in a notebook (that were written as you did them) would help to quickly transition.

I suggest writing almost everything in a notebook as you work on a project. I like to color-code and use symbols to help me find information and make it easier to read. I’ll share one of the early pages of my notebook for a project I’m working on this summer:

The notebooks I love to use do NOT have easily removable pages (no pre-perforated pages) and have pre-numbered pages. A stock photo of my notebook is to the left. Brainstorming with others or by myself, reading journal articles, data sheets, random ideas, measurements, code changes,… I put all of it in my notebook with the date and often even the time. This leads up to my second point.

Working with others on code? or even by yourself? You should be using version control.

The notebook that I keep lines up nicely with version control, so I can see the reasons I made the changes (in the notebook) and what code I actually changed (version control). I use Subversion (SVN), and after I get something working, even if it’s small, I commit the change to the repository. A repository is a relatively secure server where you upload your source code. The SVN server keeps track of file changes between commits. This means if you change one register’s hex value, looking at the difference between two versions of the file, you can easily find the previous hex value and the new hex value. You can find much more about version control here and about Subversion here.

A recent experience I had:
I spent an entire day trying to write simple communication between embedded devices by deciphering data sheets and example code. I wrote my functions and tested them on a robotic arm. They worked! It was the end of the day, so I committed my changes to the repository and went home. After two more days of work of further programming, everything stopped working. The SVN repository was futile because there were too many changes listed, and would take too long to go through. I saved a copy of my changes and reverted to the previous working copy, but now what do I have to change in the working code to catch up to were I was before? I certainly didn’t want to simply copy and paste between the copies, because there was something seriously wrong (even though possibly insignificant), causing nothing to work. Looking at my notebook, I wrote down what things I meant to implement, such as "Function to lock motor on button press." and "Function to go to a position." and within an hour had re-implemented the functions, and the ghost error was gone.

Have any tips or questions on keeping a notebook, avoiding errors, version control, or otherwise? Comment below and I’ll respond to any questions.

Mechatronics in Germany: Neuronics AG Kantana Robotic Arm

1 robotic arm + 5 DSP boards + 1 ARM-based microcontroller = a robust research platform

I am currently working as an intern in Germany at Kaiserslautern Technical University (Technische Universität Kaiserslautern). I’m helping to develop control algorithms for a robotic arm in the Institute of Control Systems (Lehrstuhl für Regelungssysteme).

The robotic arm I’m working with is a Kantana robotic arm made by Neuronics AG, based out of Zurich, Switzerland.
The robotic arm has been actively used in industry, as shown in this video clip, as well as increasingly in higher education research. The robotic arm is relatively small — when fully extended vertically it’s about 3/4 of a meter or 30 inches tall and it’s load capacity is less than half a kilogram (1.1 lbs). The robotic arm might seem like it isn’t capable of much, but it has excellent precision and range of motion with its five degrees of freedom.

Herein lies the problem: The robotic arm is precise, as it always knows the current positions of each joint and the calculations to determine the position of the end effector (tip of the arm or gripper), but knowing the proper inputs to obtain a desired position are difficult to predict. For example, without feedback, give the arm a certain amount of power (input a finite amount of energy into the system) and ask, "What is the current position of the arm?"

Reverse engineering the system and creating a valid model are invaluable for robust control. The physical trajectories of the system are calculatable, but the non-linearities of the system, such as various types of friction, are hindering control algorithms. I’ve been tasked with measuring and modeling these non-linearities.

About the robotic arm:
I’m working with a prototype arm that is not self-contained in order to access all of the control boards (DSPs) and ribbon cables that connect each joint together. The DSP boards are used to control the geared DC motors and rotary position encoders that are externally mounted on the arm. The DSPs are programmed in C++ with functions that can be called by the ARM-based microcontroller that is also programmed in C++.

In order to debug code and extract data from the system, the DSP and microcontroller are capable of two-way communication and the microcontroller can send data over a serial connection to the PC. I can measure the current input to each motor (calculated from the voltage across a shunt resistor compared to the voltage across the motor calculated from the PWM signal) and position of the motor with respect to time.

For those who are interested, here’s a look at some of the components I’m using to control the arm:
Texas Instruments TMS320F2808 (5)
NXP LPC2294 (1)
Faulhaber DC Minimotors with optical position encoders (5)

In no particular order, my lofty goal by the middle of August are to:

• Develop a warm-up procedure to ensure consistent results
  • Develop a quantitative measurement (not solely time-based) of when the robot is ‘warmed up’
• Measure current using built in measurement chip as well as an oscilloscope of voltage across the shunt resistor
• Based off of results, choose a frictional model for each joint and analyze using MATLAB
• Possibly develop a self-calibration C++ function of frictional constants that’s included in the robot warm up
  • A self-check and indicator when calibration is required

As I have just started working with the arm, I have more wild ideas than absolute plans, and feedback is graciously welcomed on my above ideas.

I feel that this type of time constrained project is a great example of a way to learn or teach mechatronics. I have had experience with microcontrollers, programming in C, design and physics, building mechatronic systems, but for this robot the chips, development software, chip programmer, electronic setup, even language of some menus are different (I am in Germany after all).

Adapting quickly to a project and to know enough concepts about an entire system — the electronics, software and hardware components — in order to start solving problems quickly and efficiently is at the heart of mechatronic design. I know I’m far from being a mechatronics expert, and I’d love to know what you think!