(ENGLISH TRANSLATION BELOW)
VIBRA har gått til innkjøp av fire sensorer fra det britiske firmaet X-IO av typen NGIMU (Next Generation Inertial Measurement Unit). Denne typen sensoren er en oppfølger av sensoren X-OSC, som har blitt ganske populær fordi den anvender Open Sound Control (OSC)-protokollen, kobles enkelt til datamaskinen gjennom wi-fi og inneholder både innebygget akselerometer, gyroskop og magnetometer, samt 32 analoge/digitale kanaler der man kan koble andre sensorer eller aktuatorer. X-OSC brukes f.eks. som «hjernen» i mi.mu gloves og i Hilmar Thordarsons dirigenthanske. Med NGIMU fikk vi alt dette samt en innebygget algoritme for absolutt orientering i en enkelt pakke som er plassert i en liten eske av hardplast som gjør også den mindre sårbar enn X-OSC.
Oppsett og klargjøring
NGIMU er svært lett å sette opp å få data ut fra, særlig hvis man bare bruker én enkelt sensor. Når man skrur den på vil man kunne se at den dukker opp på datamaskinen som et trådløst nettverk. Når man kobler seg på dette nettverket mottar man allerede sensordata, men for å kunne anvende disse må man sette opp en OSC-mottaker i et program som Csound, Max, Processing, PD eller lignende, og da med riktig portnummer og adresse (utgangsinnstilling for port er 8000). X-IO har for øvrig lagt ut programvareeksempler for ulike plattformer og programmeringsspråk på nettsidene sine. I manualen finner man en lettfattelig oversikt over hvilke sensordata som er tilgjengelig på hvilke adresser. Så langt i VIBRA-prosjektet har vi fokusert på orienteringsdata og brukt akselerometer og gyroskop-data til å få en verdi for generell «intensitet» eller «aktivitet» - altså uten tanke på hvilken retning bevegelsen foregår. I denne bloggposten vil vi først og fremst fokusere på absolutt orientering som euler-vinkler (som sendes med adresse /euler). Det er også interessant at sensoren kan sende verdier for akselerasjon med gravitasjon fratrukket og såkalte quaternions. Dette håper vi å utforske på et senere tidspunkt.
Man kan gjøre ulike innstillinger på sensoren, bl.a. endre portnummer, endre målefrekvensen (maks 400 Hz) og velge hvilke verdier som sendes over nettverket. Dette gjøres i et eget konfigurasjonsprogram som ligger på nettsidene til X-IO: http://x-io.co.uk/ngimu/ under «Downloads». Programmet er i skrivende stund kun tilgengelig for Windows, noe som naturlig nok er ganske upraktisk for Mac-brukere. På Windows virker programmet imidlertid enkelt å bruke, og har en praktisk visualiseringsfunksjon der man får opp en sanntidsanimasjon av sensoren, der man tydelig ser om orienteringsdataene stemmer med virkeligheten (se video 2 nedenfor).
Absolutt orientering
NGIMU har altså en innebygd algoritme for å regne ut absolutt orientering, altså hvordan sensoren forholder seg til retningene i et tredimensjonalt rom (x,y,z) målt i såkalte euler-vinkler. Denne algoritmen trenger ingen kalibrering, og virker relativt robust, selv om den også har noen av problemene som knytter seg til den såkalte «gimbal lock», noe vi skal komme tilbake til nedenfor. Tidligere har vi brukt Adafruit BNO055 sammen med en X-bee trådløs forbindelse for å få ut lignende data, men da var kalibrering og noe koding nødvendig for å få dataene videresendt over OSC.
Responstid
Mens oppsettet med BNO55 og X-bee hadde en ganske merkbar forsinkelse, er responstiden til NGIMU relativt lav. En måling av responstida fra et dunk på sensoren, via overføring over OSC til Csound, til det kommer ut som et lite knepp er kun på rundt 18 ms*. Det gjør at man faktisk kan spille rytmisk på sensoren.
Utfordringer når det gjelder eulervinkler
Euler-vinkler er vinkelverdier målt i grader som angir hvordan sensoren er orientert i forhold til himmelretningene, gravitasjonsaksen og sin egen akse, og da i tre dimensjoner ofte angitt som yaw, pitch og roll – eller rotasjon rundt sensorens lengderetning, horisontal helling (flatt => X = 0 deg)/rotasjon rundt sensorens bredderetning (flatt => Y = 0 deg) og horisontal retning (nord = 0 deg). På følgende video med verdiene vist i Max ser man hvordan dette fungerer:
Video 1: roll, pitch, yaw
Det er imidlertid noen utfordringer med euler-vinklene. Når Y-aksen nærmer seg +/- 90 o vil man nærme seg sammenfall av to akser. Dette kalles gjerne «gimbal lock» innen matematikk og ingeniørfag og fører til at man får store feil i målingene. Dette ser man tydelig på denne videoen, som for øvrig viser konfigurasjons/visningsprogrammet til NGIMU.
Video 2: gimbal lock
En annen utfordring knytter seg til at rotasjonen i de ulike aksene på ett punkt vil krysse over fra et maksimalt utslag i én retning (f.eks. +180 deg) til et minimalt utslag (-180 deg) i motsatt retning. Dermed kan man få et merkbart sprang i verdier. Dette blir særlig tydelig hvis man bruker disse dataene til å styre frekvensen til en oscillator. Imidlertid kan man gjøre et lite triks for å unngå et slikt hopp ved å si at man legger til eller trekker fra 360 hvis et slikt hopp inntreffer. Hvis man vet at man ikke skal rotere flere ganger i samme retning (som jo vil gi svært høye eller svært lave verdier) er dette i hvert fall en løsning som kan fungere. I videoen nedenfor ser man min VIBRA/NTNU-kollega Sigurd Saue som demonstrerer nettopp dette.
Video 3: sprang i vinkelverdier
* Gjennomsnittlig responstid over 10 målinger var 17,6ms med et standardavvik på 3,8ms. Målingen ble gjennomført ved å ta opp lyden fra et dunk på sensoren, som lå på et flatt, stabilt underlag. Dette dunket vil gi et utslag i sensormålingen – vi brukte z-akseverdien til akselerometeret – og denne målingen blir registrert via OSC og omgjort til et audiosignal som ble skrevet til den samme fila som lyden fra dunket. Ved å se på tidsdifferansen mellom de to utslagene i denne lydfila vil man få en verdi for responstida.
ENGLISH TRANSLATION
VIBRA has purchased four next generation IMU sensors from the British company X-IO. This type of sensor is a sequel to the X-OSC sensor, which has become quite popular because it uses the Open Sound Control (OSC) protocol, easily connects to the computer through Wi-Fi and includes both built-in accelerometer, gyroscope and magnetometer, as well as 32 analogue / Digital channels where you can connect other sensors or actuators. For example, X-OSC is used in the mi.mu gloves and in Hilmar Thordarson's ConDis conductor's gloves for control of electronics for mixed music. With NGIMU, we got all this as well as a built-in algorithm for absolute orientation in a single package that is placed in a small box of hard plastic that also makes it less vulnerable than X-OSC (see the image at the top ).
Setup and preparation
NGIMU is very easy to set up to get data from, especially if you only use a single sensor. When you turn it on, you will see that it appears on your computer as a wireless network. When you connect to this network, you already receive sensor data, but in order to use these, you must set up an OSC receiver in a program such as Csound, Max, Processing, PD or similar, and then with the correct port number and address (initial setting for port is 8000). X-IO has also provided software examples for various platforms and programming languages on their webpages. The manual provides an easy-to-understand overview of which sensor data is available at which addresses. So far in the VIBRA project, we have focused on orientation data as well as accelerometer and gyroscope data to get a value for overall "intensity" or "activity" regardless of the direction of motion. In this blog post we will primarily focus on absolute orientation expressed as euler angles (which are sent over the OSC-address /euler). It is also interesting that the sensor can send values for acceleration with gravity less and so-called quaternions. We hope to explore this in a future post.
Different settings can be applied to the sensor, including changing the port number, changing the measurement frequency (max 400 Hz) and selecting which values are sent over the network. This is done in a separate configuration program located on the X-IO website: http://x-io.co.uk/ngimu/ under «Downloads». The program is currently available only for Windows, which is obviously quite inconvenient for Mac users. On Windows, however, the program seems easy to use, and has a convenient visualization feature that provides a real-time animation of the sensor, clearly identifying whether the orientation data matches the reality (see video 2 above).
Absolute orientation
NGIMU thus has a built-in algorithm to calculate absolute orientation, i.e. how the sensor is oriented relative to the directions in a three-dimensional space (x, y, z) available in so-called euler angles or quaternions. This algorithm does not need any calibration, and seems relatively robust, although it also has some of the problems associated with the so-called "gimbal lock", something we will return to below. Previously, we used Adafruit BNO055 with an X-bee wireless connection to get similar data, but this required both calibration and some encoding to get the data sent over OSC.
Response Time
While the setup with the BNO55 and X-bee had a rather noticeable delay, the response time of NGIMU is relatively low. A measurement of response time from a dunk on the sensor, via transmission over OSC to Csound, until it comes out as a small button is only around 18 ms*. This allows you to play rhythmically on the sensor.
Challenges with Euler angles
Euler angles are angular values measured in degrees that indicate how the sensor is oriented relative to the directions of the sky, the gravity axis and its axis, and in three dimensions often referred to as yaw, pitch and roll - or rotation around the longitudinal direction of the sensor, horizontal slope (flat = > x = 0 deg) / rotation around the width of the sensor (flat => y = 0 deg) and horizontal direction (north = 0 deg). Video 1: Roll, pitch, yaw (above) shows the values in Max.
However, there are some challenges with the euler angles. When the Y axis approaches +/- 90 deg, one approaches two-axis coincidence. This is usually called a "gimbal lock" in mathematics and engineering, causing major errors in the measurements. This is clearly seen in video 2 Gimbal lock (above), which by the way shows NGIMU's configuration / viewer.
Another challenge is that the rotation in the different axes will cross abruptly from the maximum value (eg +180 deg) to the minimum value (-180 o) in the opposite direction. Thus, one will get a big jump in values. This becomes particularly clear if you use this data to control the frequency of an oscillator. However, you can do a little trick to avoid such a jump by saying that you add or subtract 360 if such a jump occurs. If you know that you will not rotate several times in the same direction (which will give very high or very low values), this is at least a solution that can work. In video 3, Jumps in values (above), you can see my VIBRA / NTNU colleague Sigurd Saue who demonstrates this.
* Average response time over 10 measurements was 17.6ms with a standard deviation of 3.8ms. The measurement was performed by recording the sound from a knock on the sensor, which lay on a flat, stable surface. This knock will create a bump in the sensor measurement - we used the z-axle value of the accelerometer - and this measurement is recorded via OSC and converted to an audio signal written to the same file as the sound from the knock. By looking at the time difference between the two impulse sounds in this audio file, one will get a value for response time.