Studio Contrechoc

design & textile & technology entries

Category Archives: coding

KH-940 and Teensy 3.1

The experience with the knitic board as a shield on an Arduino Due for connecting the machine knitter KH-940 with a laptop was not very positive. The board is very fragile. Connecting and deconnecting making it needing constant repair.

After the e-textile summercamp a week was spent on making a new board, connecting the ULN2803’s and programming the Teensy 3.1.

The Teensy 3.1 microcontroller has enough pin’s, it is small and cheap.

Because the Teensy is running at another speed, 24Mhz, the delay’s between the Serial command sent from the laptop to the Teensy had to be altered.

With the program code of the older board (already reprogrammed to reduce all unneccessary communications) flashed to the Teensy not only whole tours/lines were not read accurately, also single pixels inside a tour:

pix1

The mistakes in communication in red, the red borderline below indicates the mistakes in lines.

pix2

The mistakes in lines are removed, but inside the line, there are still mistakes in pixels.

pix3

Making delays between Serial asking the laptop for data and receiving the data larger, the picture is received without mistakes.

The board connecting the ULN2803’s with the Teensy had to be adapted too, because the Teensy is working at 3.3V while the sensors of the KH-940 require 5V. This 5V is taken from the KH-940. The Teensy runs on the USB. Also the Teensy is not resetting if Processing is started, like it does witht he Arduino. So the initialize function had to be refined.

knit8 ULN 2803

knit7The big connector is printed with a 3D printer

knit5The connector with 10 and 8 pins are made from 2 5 pins connectors

knit6 The board with 2 extra potmeters to make the analog read run at 3.3V.

knit4 The Teensy 3.1

knit2 Testing the knitting from the board

Teensy (arduino script):
http://contrech.home.xs4all.nl/scripts/KH-940_teensy_test_knitting.zip

Processing sketch:
http://contrech.home.xs4all.nl/scripts/knitImageInArray15a_teensy.zip

Advertisements

Bluetooth boards and the Neurosky Mindwave

For some project the Mindwave Neurosky with bluetooth was interesting. Jostie quickly made an Android App, which could connect to the Mindwave during the 2015 NASA App Challenge weekend in our neural network attempt: https://2015.spaceappschallenge.org/project/neural-network-space-fashion/.

bt8

His app can be found here:
https://github.com/Josvanegmond/Adressable

bt9 From Mindflex, with Serial to Mindwave Mobile with bluetooth

But we wanted the signals directly available for a wearable. For this a bluetooth board was needed, which could connect to the Mindwave. Several options were available.

By studying two tutorials constraints for this setup are becoming clear:

  • The board has to have the possiblity to behave as a master, connecting to the Mindwave.
  • The communication has to be Serial (that is fast) and not SoftWareSerial (two reasons for this!)

Tutorials:

We tried different boards (although we could have guessed that only the boards mentioned in the tutorials would function 🙂 —stubborn!—


bt3  older BT board, old – hard – school – command coding RX-TX connection

Easy Bluetooth (http://www.parallax.com/ not for sale anymore?)
This is an “older” board, from a few years ago. No problem connecting and using as a slave. There is more: https://www.jameco.com/Jameco/Products/ProdDS/2109261.pdf. In this pdf of 100 pages you can see that you can enter the command mode, and make this board a master. But … this is the real stuff in command BT-coding, will cost some time to study.


bt5 see the wires: SPI connection: 6 besides the V and GND

Bluefruit LE – Bluetooth Low Energy (BLE 4.0) – nRF8001 Breakout (http://www.adafruit.com/)

A recent board. Communicating easily with an app, sending to a wearable. This board is easy to connect to, but functions as a slave. So for our purpose this board cannot be used. Besides, compared to the other boards, the SPI connection has a lot of wires…

The documentation from Nordic is also extensive: https://www.nordicsemi.com/eng/content/…/2981/…/nRF8001_PS_v1.3.pdf .


bt4 very nice, “designed” connection at the FTDI of this RF12 board

Bluefruit EZ-Link – Bluetooth Serial Link & Arduino Programmer – v1.3 (http://www.adafruit.com/)

This is a board with some nice possibilities as can be discovered here:https://learn.adafruit.com/introducing-bluefruit-ez-link/tour.

It can be connected to the FTDI header of a Jeenode, making the Jeenode having both the RF12 and bluetooth wirless.

The board has an optional JST connection. So you can make a standalone module witha lipo attached. Only problem: the lipo in the JST connector is always on: no on-off switch. So in practice this connector requires soldering a switch in the wiring to the lipo, which is not fun.

But as can be read in the FAQ of Adafruit:
Can EZ-Link act as a BT ‘master’?
No, it is a client-mode only device.

End of story for our purposes.


bt1 without the BEE carrier, programming with the AVR SPI mkII

Bluetooth Bee – Standalone ( http://www.seeedstudio.com )

This board has a bluetooth part combined with a ATmega168P (Not an ATmega168 as told in the wiki).

The wiki can be found here:http://www.seeedstudio.com/wiki/Bluetooth_Bee-Standalone.

Getting this board working did cost more time. Using an AVR ISP mkII programmer (not the X Bee carrier) was the first hurdle. After a while the J1 connector functioned – or the configuration was understood.. Uploading code was possible after adding the ATmega168P code to the Arduino boards.txt file, using the shift-U command in the Arduino environment.

Screen Shot 2015-05-07 at 09.54.15 Screen Shot 2015-05-07 at 09.55.27

(Our AVR ISP mkII is hacked so that it provides either 5V or 3.3V directly to the board – this one needs 3.3V.)

The LED’s (red-blue) on the BT board code as follows (no the description in the wiki): Master mode: double fast blue: not connected, single blue: connected. Waiting to pair: red, blue alternating.

If paired right from the laptop you get a BT – Serial link in the Arduino environment. Opening this as a serial monitor initiates the pairing, the key “0000” is given automatically. The board is in slave mode. The example code worked, the led could be lit and “shut”.

Screen Shot 2015-05-07 at 09.55.02

But the master mode is needed.

At this page about the Bluetooth Bee you can find the commands :http://www.seeedstudio.com/wiki/Bluetooth_Bee

The code used to get the master mode using the commands can be in the scripts at github:

 https://github.com/contrechoc/Meab_scripts/blob/master/bluetooth_bee_standalone_master

The communication is done using SoftwareSerial. On this board communication is hard wired using pin’s 2 and 3. See the schematics at: http://garden.seeedstudio.com/images/f/f6/Bluetooth_Bee_Schematic_Board.zip.

This hard wired connection is the problem for our project. For the Mindwave to give signales regularly a faster connection is needed than the SoftWareSerial can provide—the “normal” Serial connection on pin 0,1 is much faster—, as will be seen in the last bluetooth board which is tried out. The signales are coming through with SoftWareSerial, but apparently there are so many bits falling out that sometimes you have to wait seconds or even 10’s of seconds for new values of the Mindwave.

The script using this Bee Standalone board can be found here: (mind the baudrate which is set at 57600, default 38400 – start using this value to set the baudrate at 57600). It functions, the LED signals received values from the Mindwave, but not too often and at irregular intervals.

The second problem for our project is also related to using SoftwareSerial. We want to transfer the values from the Mindwave to servomotors. But the Servo lib and the SoftWareSerial lib are incompatible (probably they use the same timer).

So also this board is not what we needed.

Nice post in Japanese: http://leibun-tech.blogspot.nl/2012/12/bluetooth-bee-standalone-android.html,


bt2 nice and clean, connected to an ATmega328 board with RF12

 BlueSMiRF Silver (https://www.sparkfun.com)

This board was mentioned in both the relevant tutorials. So no wonder that this board functions. Using the command mode it can be programmed in Master mode and the MAC address of the Mindwave can be entered. Connection and reconnection is done automatically.

In our project we spent time using the SoftWareSerial instead of the Serial port, with the intention of debugging. The speed difference resulted in dataloss (apparently) and only some packages of the Mindwave were received in minutes. With the Serial, pin 0,1, Mindwave values enter once or even twice a second.

SoftWareSerial was used to communicate with Coolterm (or other Serial monitor) to see what was happening and debugging. This interfered with the servo motor lib.

The ATmega328 board (Jeenode) with the RF12 provided a solution: bluetooth signals from the Mindwave are received using the UART of the Smirf, then the signals can be transmitted using the RF12 transceiver. These signals can be received in a similar board.

Scripts using the Mindwave and this board can be found at:

https://github.com/contrechoc/Meab_scripts/tree/master


The projects with these boards and scripts will be presentated later…

bt7

Victory over the Sun: technical testing

The dress described in former posts was finished finally.

https://myfablab.wordpress.com/2015/04/06/victory-over-the-sun-version-1-0-energy-considerations/

The dress as a result of an artistic research into energy harvesting and design is presenting a game situation. By rotating a dynamo you have to compete with the Sun and a solar panel in generating energy. The game is created in a wearable so that you can change to another location. Playing the game in different locations makes you aware of the power of the Sun’s energy in comparison to your own muscle energy.

The dress is very much a prototype. As can be seen from the electronics a large amount of testing is needed to make some sort of a playable game.

The electronics was fitted inside 4 acrylic casings:

vos2

dynamo charger, supercaps/lipo, the brains: 2 ATtiny85’s and bitshifters, and an LTC3105 energy harvesting chip.

then fitted to the side of the dress: (which makes us aware that we should have thought of a better wiring 🙂

vos1

Up left: the charging dynamo, up right, the ATtiny85’s, and the bit shifters, down left, the supercaps, and lipo, then bottom right, the LTC3105 for recharging the discharged energy into the lipo.

After fitting the casings will be covered with small pieces of jeans, only the dynamo charger will be visible.

vos3

Two out of the three casings covered.

The choice for 2 ATtiny85’s was made from the first version where we had only 4 LED’s for the two sources of energy. But now after making it all we realized that the 2 ATtiny85 with the bit shifters should have been replaced by one ATmega328, with a LED-block script, avoiding the bit shifters. This would have saved one casing. This will be done in the next (third) version of the electronics.

Testing!

Besides the solar panel a battery pack is installed to make testing in a room without the Sun easier, you can test by switching to battery pack (right side, next to the solar panel). The wiring between all the casings and groups of electronics is done by female – male connectors. This makes testing easier.

vos5

The second version of the script discharged the supercaps after winning. Winning is reaching the 5V mark. But what about starting a new game after abandoning a game half way? It was decided to discharge the supercaps at the start, when you switch on. Discharging is not what is seems. Following the voltage of the supercaps to about 0V, you see the voltage rise again without any charging. So discharging is now done in steps, then some delay, then measure the voltage again, if it is above a limit, discharge another round and so on.

This repeated discharging worked…until the dress was put in the full sun. The solar panel is generating so much energy that the discharging is not fully obtained. The discharging time had to be made bigger.

The installed solar panel is doing 0.1V a second so it will win in 50 seconds if the Sun is not hindered by clouds. At the moment it is practically impossible to win this using this hand crank dynamo hacked from the Ljusa.

Besides that, as could have been expected 🙂 the big LED’s are not visibly on or off in the full Sun. Another interface should be added, or these LED’s like this removed and giving it a try with small superbright LED’s.

A movie of the solar panel racing towards the 5V:

http://youtu.be/AS1miVtdD00

After observing the problem of the LED’s not visibly lit in sunlight, we tested bright LED’s in a simple script at 3V:

http://youtu.be/GDRzv7O-mU0

So the big 10mm LED’s will be replaced by these 3mm bright LED’s.

2015 NASA App Challenge

Two years ago we participated with friends in the 2013 NASA App Challenge with a wearable. Last year we did a game for the 2014 App Challenge. Now we do another wearable challenge in the 2015 NASA App Challenge: https://2015.spaceappschallenge.org/

This is the first time we really try to make “intelligent” garments. We will integrate a neural network in the wearable. This network will “learn” by trying to recognize patterns. This learning will be made visible by changing the shape of the wearable, or even morphing.

The neural network will be small, and the learning capacities will be very limited, but this is a start at “really (somehow) smart” fashion.

Details about this project can be found in this hackpad:

https://spaceapps.hackpad.com/Neural-network-Space-Fashion-cCVR3PzAqtf

images will follow next week when we try to finish two wearables in one weekend, where normally it takes about a month for a wearable…

But now we come with a group of expert programmers, designers and e-textilers, together with a car full of equipment…

(Making tags for this post … nearly all tags created for this blog are indicated, which means that something will be happening!)

Project page:

https://2015.spaceappschallenge.org/project/neural-network-space-fashion/

Victory over the Sun – (sketch version)

(see http://etextile-summercamp.org/2015/victory-over-the-sun/ for a more advanced version)

Intro
This wearable is part of a research into energy harvesting, which can be found here:
http://83.160.137.124/wordpress/wordpress/ (Slow Raspberry pi server!)
The purpose of this wearable is to compare two sources of energy, not just showing a charging wearable.

Title
The title of this project has changed a few times:

  • 1. Not another solar dress
  • 2. Energy battle dress
  • 3. Victory over the Sun

The first title is indicating that this project is not another mobile phone charging wearable. There is a solar panel, but also a hand crank device in the dress. But it is not about charging anything, because charging from a wearable is anyhow not very efficient.

The second title is indicating that the purpose of this wearable is comparing two sources of energy together in a game. The two source compete against each other. Which one will win? The solar energy or the muscular energy?

The third title is a reference to the oper of the Russian avant garde in the Bauhaus time:
http://en.wikipedia.org/wiki/Victory_over_the_Sun
Malevich and El Lissitzky made this oper famous, contributing to the stage design and the graphical displays.

There is some sarcasm in this third title, because it is rather impossible to win from the Sun in this game, only at night you have a chance, the solar panel is even charging slowly in normal daylight without direct sunlight.

Materials:
Appropriately for the material old discarded jeans are chosen. Thus the material is recycled. The wearable is a simple dress with possibilities to add panels and the hacked Ljusa hand crank.

Design:
From the parts of jeans which were not totally worn out pieces were cut and these pieces were sewn together. An interesting folding problem popped up which will be described in another post.

Picture of the wearable in progress: (The hacked Ljusa, with the white card board and the red crank will be redesigned and more properly inserted into the wearable of course)

http://83.160.137.124/wordpress/wordpress/preparing-the-course-hacked-gadget-ljusa/

2015-03-12 07.51.57#1

Wearable made of recycled jeans material.

Electronics.
For the hand crank I have chosen the Ljusa of IKEA, which is a toy generating some power. It stores the power too in a 1.5F supercap. The second source of energy is a solar panel. Added to this is also a 1.5F supercap. With a ATtiny85 and 8 big LED’s – 4 LED’s for each energy source – the winning source can be made visible.

The electronics idea was to show the current Voltage for the two sources in two rows of 4 LED’s. The microcontroller which can just be used is a ATtiny85. Two analog PIN’s and two PIN’s for a multiplexer chip. One PIN is left for one other purpose.

Although the sources are generating energy, there has to be another energy source for the microcontroller at the moment. It would be an nice idea to have the sources (solar and muscle) first generate enough energy for the game to start, but this has to be figured out yet.

The third energy source is a rechargeable lipo battery.
Then there has to be a discharge for the game to restart. This is done using a FRT5 DC5 relay.

The number of difficulties in the electronics were plenty: besides the usual stupid mistakes like connected the LED’s the wrong way there were a few real “Zen master” problems (which means you have to learn something besides correcting stupid mistakes).

The ATtiny85 uses USI instead of SPI, code for this was found at:
https://github.com/JChristensen/tinySPI/blob/master/tinySPI.cpp

Then the implementation of the use of the analog PIN’s proved time consuming. In the end the soution was found in connecting the PIN’s to the GND using a 1M Ohm resistor.

Then the coding of the LED’s, in two groups of 4 inside the bigger group of 8 was proving not straightforward. Apparently the number read using the ADC code is not a “normal” INT number and you cannot use all math available, like subtracting 512 from the value read between 0 and 1024.

The final code can be found here:
https://codebender.cc/sketch:94401

Testing pictures of the electronics:
Testing is better down as much as possible outside the wearable. In the end the electronics is on the board and the ATtiny85 had to be removed and placed in the programmer breadboard way too often again, I could have better soldered programming the wires to the board right away…

  • testing first the ATtiny85 and multiplexer on a breadboard
  • testing the LED’s on a piece of jeans
  • the PCB with the supercap, multiplexer, relais and ATtiny85

2015-03-16 08.09.00 2015-03-16 11.18.50

2015-03-17 10.38.49

Remarks about the PCB:

  • One relais too much, two components right upper side FRT5!
  • At the left side the two energy sources can be connected.
  • The green component is the 1.0F 5.5V supercap
  • The Ljusa has it’s own supercap (storing energy), the solar panel uses the supercap (green thing) on the board.
  • Middle under, ATtiny85, left under hd74ls164p shift register
  • The PCB can be redesigned more efficiently!

Social Wind: development of the yellow motor holder

The 3D printer allows to make a nice connecting shape between the textile and the electronic hardware. For “Social Wind” i have chosen  3 phase motors:

2015-02-09 19.15.03#1

The problem (in the old days) was how to sew the motors inside the jacket. Nowadays this is not really easy using the 3D printer, because you have to print quite a lot of tests, but you arrive at a nice holder of the same color as the fabric – or the color you need.

The cooling effect comes from ventilators, not for example Peltier elements. The ventilators provide a gentle cooling effect and are at the same time a nice moving shape. The Peltier elements would be inserted in the fabric and not even visible. This leaves absolute freedom for the design, but hides the functioning.

The development of the shapes to hold the motor in this jacket can be seen in this picture of all the shapes printed for these 5 motors which will be sewn in the jacket:

2015-02-09 19.12.56

First I tried to print the whole ventilator as one piece. No doubt with an expensive 3D printer this could be done, but with my terrible ROBO printer a better option was to print the axis and the blades seperately.

2015-02-09 19.15.48

Because the five ventilators will be running close to each other, the ventilators rotate against each other. This has to be tested first:

http://youtu.be/mjya89T0LVA

Later on the axis were made higher and lower, so the ventilators could run close together.

All the five attached to the microcontroller:

http://youtu.be/s-7KOpNqks8

The motors run at 5V which is probably too low. So the power of the motors is big enough for small blades, but these blades are to big if you start right away at a fairly high speed. The solution was to start slowly and build ip momentum. Then the motor can rotate these 5 blades without a problem.

The STL files will be available soon.

 

 

 

 

 

 

 

 

 

 

 

 

KH-940 scripting details

As told in an earlier post,

https://myfablab.wordpress.com/2014/10/11/writing-my-own-software-for-the-kh-940/

the knitic.com software didn’t work with my combination KH-940, Arduino Due and MAC laptop. Their software is probably device dependent, like my code is! The device dependency could be due to the lags in communication between the Arduino, knitter and laptop.

I decided to program my own scripts, thus learning about the sensors and the problems involved.

In this post I publish remarks around the first scripts which can be found at github:

https://github.com/contrechoc/kntting_code

In this post i reproduce the README file, with a few images from the KH-930 manual:

README on Github:

Be careful: the communications are probably device dependent, the knitic code didn’t work for my machines. That’s why i wrote my own. This software could just not work on yours because of the same reason!

The connections/board are in principle the http://www.knitic.com/ board (but for one PIN):

for needle PIN’s: (my PIN 2 is fried.)
digital: 3,4,5
Solenoids array: digital: 22,24,26,28,30,32,34,36,37,35,33,31,29,27,25,23
right/left solenoid sensors: analog 0,1

Programming concept: all pixels are sent in CHAR’s one pixel is one bit. send as less information as possible beteen the Arduino and Processing

Preparation:

Processing:

  • step 1: sample image and to be send to Arduino in char code that is 8 bits of information (pixels) in one char. step 1a: add 4 lines in fron of the image – see detail 2
  • step 2: waiting for the arduino signalling start sending image
  • step3: sending image line by line after a signal from the arduino
  • step 4: receiving the control image and displaying this image, waiting for knitting to start

Arduino:

  • step 1: asking for the image after some start up time
  • step 2: asking for img width and height
  • step 3: asking for image line by line (tours) in char code.
  • step 4: sending back a check of the image

 

Knitting: (starts at right side only at the moment)

Arduino:

  • step 1: reaction on right sensor: send one line to knitter
  • step 2: count stitches from needle sensor information 1,2,3,4 rithm, done by interrupt functions
  • step 3: react om passing the middle
  • step 4: changing direction (deduction from 1,2,3,4 reversal)
  • step 5: send line to processing

Processing:

  • step 1: receive knitted line, displaying as a transparent overlay in the image, no information of needle count is displayed
  • step 2: sound signal after direction reversal
  • step 3: after the knitting is done: sound signal to indicate end of image

Detail 1:

critical in the Arduino code are the (hard coded delays) eg in the loop to receive the image:

delay(10);
Serial.println("w");///sending code to ask for image width
delay(7);//necessary, otherwise loss of data

change these values and information can be lost

Detail 2:

The first 4 lines transferred contained random errors, from the 4th line on information was processed without errors. This was solved in a rude manner: insert 4 extra lines at the start of the image and ignore these 4 lines in knitting.

Detail 3:

The image is kept in the memory of the Arduino sketch. This was not possible in INTEGER format. In CHAR format it is, but of course the image can in principle have an infinite length (while width has a max of 200). Also the CHAR array has boundaries. At the moment the maximum value is: 200 tours (lines of knitting).

Detail 4:

The KH-940 needle sensor information. With interrupts the needle information is processed. There are two signals alternating for each needle. These were given a code 1,2,3,4 and from this the direction is deduced. When reversing direction counting is done backwards, not losing any needles.

Captura de pantalla 2014-10-11 a la(s) 19.17.21

Detail 5:

The right and left sensor. The right sensor is used not for putting the needle count on 0, but for deducing the distance between the needle 0 and the position wehre the carriage combines with the belt – solenoids offset. By trial and error was deduced that there are 4 significant combining positions, which can be reduced even further, with a special offset. After introducing these belt offsets, the image didn’t shift anymore.

encoder graph

Detail 6:

Does this mean that I exclude knitting direct sensor information? No, because a sensor connected to the Arduino can influence the row to be knitted. But because anyway, you have to correct for direction of knitting when doing eg a graph, you have to program this case individually independent of the background image sent from the laptop.

 

Writing my own software for the KH-940

Last year in 2013 I joined the lobotomy workshop of http://www.knitic.com/ in Bruxelles. We made this knitic board (now called the first version) and did some experiments, which failed using my board on a KH-940. But in the end I was happy anyway, full of plans to make this work! It took a bit of time!

On the school (www.wdka.nl) we had the KH-940 knitters but I didn’t want to test too much on these machines for the students. After a fail I abandoned the experiments.

Before the summer I bought my own Brother KH-940 which I tested during the etextile summercamp: http://etextile-summercamp.org/ I discovered much more than the Nordic knitting technique!

For me the knitting of images using the Nordic technique was already “normal”, we could do this using Designaknit at school: https://myfablab.wordpress.com/2013/02/04/design-process-of-a-sustainable-e-scarf/

Back in Rotterdam, besides discovering patent, slip, tuck, ajour (knitting a sock too 🙂 ) I could try to re-lobotomize my knitter. Then (after lots of frustration) I analyzed this board and by measuring I discovered that the PIN 2 of my Arduino Due board was always GND. Since this was a PIN used by the needle count it was obvious important signales were missed. This was easily fixed by assigning another PIN.

During the summer I used the software of http://www.knitic.com/ but i noticed that lot’s of time the needle count was lost and the image shifted out of view: http://etextile-summercamp.org/2014/solar-cell-efficiency-energy-harvesting/

I decided to program my own software. That took some time, analyzing the sensor information and building up the Arduino software in combination with the Processing software.

The main point discovered was that the sensor information from the knitter was lost if you sent too much information to the laptop. The knitter is sensing a lot of stuff and we need it all. So in the end the information sent to the laptop is minimized as much as possible.

(and what do you do when software is not working? you add checks, in this case sending more and more information to the laptop….resulting in a real knitting disaster, because then even more signals were lost. 🙂

The second point was getting the offset right for the solenoids. This took some figuring out, because the belt and the carriage have several ways to connect. By discerning between four ways to combine carriage and knitter apparently all possibilities were tackled.

My software is tested further, and I suspect that there will always a dependency on the type of laptop, because the Serial Port always needs some time to “digest” between sending and receiving signals. So if either the Arduino or the Processing sketch go too fast between sending and receiving on either side information can be lost. (The laptop itself, when attending other tasks, can also be a cause for losing information as could be seen in my interface, where sometimes the image is truncated.)

The processing sketch has a basic interface, showing the image and the tours you are knitting. A few nice sounds accompany you while knitting and signaling the end of the knitted image.

Hardware board: basically arduino Due + connections to the KH-940 sensors and 2 ULN2803.

See: http://www.knitic.com/download/, although their board is much more nice now then mine, which was their first version, but is works. And they have developed this fantastic double bed version!

2014-10-11 13.10.56 2014-10-11 13.11.02

Basic interface made with Processing, showing the image, and the tour you are knitting.

2014-10-11 10.14.35

Needles are set according to the knitted tour.

2014-10-11 10.14.51

My fascination is to use the “other” possibilities of the KH-940 for datavisualisation: the slip stitch, the patent stitch, the tuck stitch, well that is starting to become possible…..see next post).

Working at a 3D printer at the same time with the same imagery of datavisualisation you notice one thing: the knitter is not a printer! The knitter is much more like a usical instrument. Knitting will always involve handwork, never be a push the print button and wait action…..:-)

The software can be found here, but as mentioned there is a dependency on laptop, so be careful! First version not documented yet. Still testing!!!!

https://github.com/contrechoc/kntting_code

One remark about Open Source. I always like Open Source code, because it allows you to start fast and comfortably. But then you have learnt nothing,  beacuse you are using other people’s code. If something goes wrong….you have to do it yourself anyway. Making it yourself costs a lot of time. But then you have your own code, you know the structure, and you have learnt something…

Open source is a bit like Fast Food! Better also do some Slow Cooking!

Se more scripting details in this post:

https://myfablab.wordpress.com/2014/10/12/kh-940-scripting-details/

 

Supernova dataviz textile 1

Supernovas are exploding stars in the universe. They are so bright that these stars can indeed be seen throughout most of the universe. They serve as distance markers and track the speed at which the universe expands. Supernova observations have shown an acceleration of the expansion, where this wasn’t expected leading to unknown territories: forces that are not incorporated in any theory up till 2000.

supernovaGar1Captura de pantalla 2014-09-14 a la(s) 11.47.53

DSC08847

Visualizing the exploding stars seems far away from our body and thus not very connected to garments. But these explosions is also quite “related” if we realize that all the atoms in our body are only made in these extreme exploding stars. We could not have been around if the supernova’s were not dispersing these atoms in the interstellar medium.

We have made a crude visualization of a few of these observations. The flashes are shown on a garment which shows the whole sky. This image is the Microwave background radiation printed on a t-shirt. The oval shape is a special projection called the Mollweide projection.

The Microwave background radiation is at the other end of time in the universe, on the other hand it represents the distribution of mass which leads to galaxies and stars and ultimately to exploding stars.

This picture is a Python Image in Mollweide projection of supernova observations of the first half of 2014: (the numbers are referring to one of the 5 led pannels). (Hopefully all the transformations are done in the right way 🙂

Captura de pantalla 2014-07-21 a la(s) 12.02.27

Because a t-shirt is not a screen we had to divide the sky in 5 parts, and if an observation is in these huge parts a led-pannel flashes. The visualization is speeded up: one day has become one second.

Here you can see the action.

http://youtu.be/s4s76GpxW7Y

In principle the idea was to really have a “live” connection to the universe using a wireless connection from a computer which checks the html page where astronomers put the observations of these exploding stars. For an exhibition in a space with a poor internet connection we have put the data in the script of the microcontroller.

Presentation:

http://etextile-summercamp.org/2014/exhibition/

Technology:

microcontroller (ATmega328), with LED pannels (12V), using TIP122 transistors.

Three lipo batteries

Observations Source page:

http://www.cbat.eps.harvard.edu/unconf/tocp.html

Scripts, Python and Arduino (Wiring)

https://github.com/contrechoc/supernovaDataviz

Mollweide projection of the Microwave background radiation : (amongst many other pages explaining this)

http://www.universeadventure.org/big_bang/cmb-origins.htm

 

 

Night of the Nerds 2014

Contrechoc presented at http://www.nightofthenerds.com/

print screen beurs notn

A panoramic view where the Contrechoc table is in the center.

The presentation is showing various research items to give an idea of the complexity of e-textile design.

nn3

The solar rim dress with laptop showing images of the Sun rotating. The images are sent to the dress. Two images for every day from Januari, 2014 were shown to see the differences in display.

nn5

Also the E-textile swatchbook was shown.

nn4

In front the public could experiment with thermo chromic effects and at the right side you could explore static electricity on different conductive materials.

nn2

Conductive materials from the e-textile summercamp 2013 doggy bag.

nn1

In the middle the solar cap, which can be harvested for a solar cell and an related motor. This motor with black feathers glued on it was given power from an arduino board. When rotating the feathers collected static electricity. This was indicated by the darlington array:

nn6

The static electricity explorer: a darlington array. The 2014 contrechoc swatchbook contribution.