Mechatronics on Campus

Mechatronics Improves and Speeds Up fMRI Scans

The inside of an MRI cavity is precisious real estate, why would you want to share this potentially closterphobic space with a robot?

In a recent release of the IEEE/ASME Transactions on Mechatronics, one article particularly caught my attention. Functional MRI scans (fMRI) are a type of brain activity scan where an image of brain activity, based on blood flow, is captured every couple seconds. The patient is often told to do a specific task, but these tasks are limited within this space. This single degree of freedom robot, more similar to an actuator, can provide resistance, measure a patient’s force, or guide a patient’s hand in a certain way. This all happens while inside of a machine where a single hair pin could be deadly. A typical fMRI machine produces a magnetic field of 3 Tesla and sometimes as high as 6 Tesla. The earth’s magnetic field is on average 0.00004 Tesla, or 75,000 times weaker than a fMRI magnet.

Shown above, the entire actuator must be made of materials that do not interfere with the magnetic field of the fMRI machine, must be guaranteed to work properly while inside the machine and must not make the 55cm to 70cm aperature of the MRI any more cramped than necessary. The senors, actuators, and device structure are simple to implement out of traditional parts, but these must not cause interference with the magnetic field. This rules out all electronic sensors and ferromagnetic transmission wires, as the metal would be dangerous in the magnetic field, but also an electronic sensor would be innacurate in such a strong magnetic field. The paper compares the options between hydrodynamic and pneumatic actuators.

These actuators use fluid lines instead of electrical lines to ‘transmit’ force to an electronic sensor at a large distance from the MRI machine. The best part of a fluid line is how it is actually a wonderful physical analog of electrical system: voltage as pressure, and current as volume flow rate. This simply means that if the tubing does not expand, and the fluid is not compressible (water is not very compressible), that a hydrolic line, esentially a polymer pipe, is perfect for this application. The fluid and the pipe are magnetically inert, ‘power’ in the form of water pressure can be created at a distance from the MRI unit and sent to the actuator. The end effector, or handle the patient moves (pictured previously), is relatively easy to create out of MRI safe and non-interferring materials.

This system is a very simple mechanical and electrical system, but it is a vast improvement over an operator telling the patient to move their fingers. Now there is a quantifiable measurement of force linked with the brain activity. I find simple solutions that are novel, realiable, and useful are some of the best mechatronic applications. In order to see these solutions, often you have to have experience looking from all angles at a problem. Engineers who are educated at the union of different fields who will make progress to solve some of our most complex problems.

Original article at IEEE (IEEE membership and subscription required)

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.