Camera Pi

Today, I was wondering with a friend of mine (whom I hope to see soon, in here) about the chance of sending a wireless video stream, from a dslr camera to a remote device, eventually with arduino.

Tonight I quickly googled the thing and, at first, I only found canon’s proprietary solution, and a few web pages with some (not too convincing, when not clunky) proofs of concept, or related technologies:

But then I bounced into a more interesting article by David Hunt, dealing with DSLR cameras with an embedded computer, using Raspberry Pi.

Possibilities include:

  • Wireless tethered shooting – attach a Wifi dongle to the USB port, so I can transmit pictures to a PC or tablet PC as I’m shooting.
  • Attach a USB memory key or hard drive so I can back up the images on the camera.
  • Remote control the camera using a PC, tablet PC or smartphone (from anywhere in the world).
  • Intervalometer – take a picture every few seconds for those high-speed sunset sequences, including exposure adjustment as you go.
  • On-the-fly image conversion for faster previews on remote display device (iPad, etc).
  • Add a small LCD display to give status, allow user input via buttons, etc.
  • Trigger camera via shutter release port, also allows waking up of sleeping camera, which cant be done via USB.

A side note: tons of enthusiastic comments follow the post, with many Kickstarter suggestions.

 

Opendolly #1 primi passi

Again, Italian only by now, sorry.

::

Come anticipavo nello scorso post, il primo aspetto di openDolly che ho scelto di affrontare è il controllo dell’otturatore.
La scelta deriva (prevedibilmente) dal fatto che su questo si basano tutte le funzionalità di timelapse e stop motion; oltre a questo, si trattava decisamente del problema più semplice da affrontare, sia per quanto riguarda l’implementazione del codice, che per il setup dell’hardware.

Controllo Otturatore

Il primo aspetto che ho dovuto considerare è stata la modalità di innesco dell’otturatore.
La mia 7D, come tutte le Canon e quasi ogni altra DSLR, può essere controllata via cavo o infrarossi. Per quest’ultima opzione, si trovano diverse librerie (ad esempio qui) e immagino altrettanti tutorial.

Nel mio caso, però, ho scelto l’opzione del cavo, praticamente da subito, per una varietà di ragioni.
La prima è che il vincolo di prossimità dato dal cavo è relativamente ininfluente, dato che sul dolly le parti son tutte vincolate fra loro, comunque.
Inoltre, la macchina non legge gli infrarossi quando va in stand by, per cui questa soluzione costringerebbe l’utente a disabilitarlo; sarebbe una cosa in più da ricordare e consumerebbe più batteria.
Infine, la posizione del sensore IR sul fronte della macchina m’avrebbe costretto a installare un mini-rig per tenere il led in una posizione visibile dal sensore stesso. Questa, almeno, era l’unica soluzione che avevo trovato percorribile, prima di accantonare l’idea (almeno per ora).

Quindi ho cercato di raccogliere un po’ di informazioni su telecomandi e in generale controlli via cavo, tendenzialmente per i modelli Canon ma non solo.
Quello che ho trovato è che molte Canon (e Pentax) utilizzano il comune mini jack (TRS) per controllare autofocus e otturatore. Sfortunatamente, nel caso della mia 7D (e di tutti i modelli simili o superiori) il connettore è proprietario (vedi link a seguire, dove si menziona N3 connector).
Di seguito, una raccolta delle pagine che ho trovato:

Un paio di link extra, anche se un po’ fuori tema, li lascio a parte come spunto per altri progetti:

Primo test

Di quelli presentati sopra, il link che ho trovato particolarmente esplicativo e completo è quello su OpenMoCo.

La prima cosa importante che ho imparato (per fortuna non a mie spese, mi fido sulla parola) è che non conviene rischiare di bruciare la propria macchina fotografica.
Per evitare il pericolo a monte, si usano degli optoisolatori; grazie a questi, si può isolare elettricamente il circuito collegato ad Arduino (che gestirà la logica dell’intervallometro e dei controlli motore) dal circuito della macchina fotografica, pur permettendo la comunicazione fra i due.

Seguendo le indicazioni del tutorial (OpenMoCo pare abbastanza serio da potersi fidare) ho preso due 4N26 e due resistenze da 560 ohm, per poco meno di 3 euro.
Sempre da tutorial, prima di collegare la macchina fotografica ho testato l’optoisolatore con un led. Come resistenze ho provato sia con 330 ohm che 560 ohm (seguendo anche altri schemi trovati online); francamente non so nemmeno se avrei dovuto riscontrare differenze, comunque al momento funzionano entrambi.
Il circuito appare così (grazie ad Alan e Luca per avermi guidato in queste prime, noobissime fasi):

Chiaramente, in questo caso i circuiti sono isolati solo idealmente, ché per alimentare il led ho comunque usato Arduino.
Per il codice degli sketch, potete fare riferimento al tutorial; l’ho ripreso paro paro.

Dato che i test parevano funzionare, sono passato al cavo con il connettore N3.
Nel mio caso, il cavo bianco è la terra, il giallo controlla l’autofocus, il rosso l’otturatore.
Nel caso di connettore mini jack, la terra è lo sleeve, il fuoco è il ring, lo shutter è il tip.

Per ora ho brutalmente collegato i singoli cavi a dei jumper dello stesso colore con il nastro isolante.
Quello che vorrei fare presto è saldare un jack (o una femmina) TSR, all’estremità opposta al connettore N3. In questa maniera, sia per i test su breadboard che sul prototipo finale, potrei montare su circuito direttamente un attacco TSR: sarebbe già predisposto per l’uso con macchine diverse.

Parallelamente, ho cominciato ad abbozzare un schema del circuito, con un optoisolatore per il controllo del fuoco e un altro per l’otturatore.
Non sono certo che sia corretto, ché non ho ancora provato questa soluzione. In effetti, non sono nemmeno sicuro che mi interessi controllare il fuoco, per il momento. Nella gran parte dei casi, sia per i timelapse che per la stop motion, il fuoco sarà regolato manualmente o tramite motion control.
Di seguito, avete lo schema che ho schizzato su circuitLab (qualcun altro l’ha provato? mi pare pratico, per cose semplici):

Per testare la macchina fotografica ho ripreso l’ultimo sketch del tutorial e fatto solo pochi aggiustamenti qua e là.
Lo sketch utilizza una libreria esterna, MsTimer, che va ovviamente scaricata prima di compilarlo; a quanto pare, l’ultima versione non è disponibile sul sito di Arduino ma qui.
Questo il codice :

#include <MsTimer2.h>        // allowing interrupts

#define SHUTTER  13      // camera shutter trigger

#define INTERVAL 5000    // shot interval time
#define EXPOSURE 2000    // exposure length (B pose is to be used)
#define SHOTS    15      // number of shots to fire

unsigned long lastShot = 0;  // last time our camera fired
unsigned int shotCount = 0;  // number of shots fired
bool exposing = false;       // shutter state; open when exposing = true
bool finished = false;       // sketch executed until the end

void setup() {
  pinMode(SHUTTER, OUTPUT);  // set shutter pin as output
  Serial.begin(9600);        // for debugging
                             // data rate: 9600 baud (bps) ; was 19200
}

void loop() {

  if( !exposing && millis() - lastShot > INTERVAL && shotCount < SHOTS) { 
  // if camera is not exposing and timer elapsed, fire camera

    MsTimer2::set( EXPOSURE, closeShutter );   // set timer interrupt
    MsTimer2::start();                         // run timer

    digitalWrite(SHUTTER, HIGH);  // enable optocoupler
    exposing = true;
    shotCount++;

    Serial.println(String("shutter open : ") + shotCount);
  }

  if( shotCount==SHOTS && !exposing && !finished){
     Serial.println("last shot reached\n");
     finished = true;
  }
}

void closeShutter() {
  digitalWrite(SHUTTER, LOW);     // disable optocoupler
  MsTimer2::stop();               // disable timer   
  lastShot = millis(); 
  exposing = false;

  Serial.println("shutter closed\n");
}

Ho pensato, per praticità, di caricare lo sketch (e i prossimi che produrrò nell’ambito di questo progetto) su github, il repository è:
https://github.com/mapofemergence/moeMoCo

Fin qui, tutto pare funzionare. Spero di riuscire a preparare anche un videuzzo dimostrativo.

Considerazioni

Una cosa che conto di iniziare a fare presto, è un prospetto dove raccogliere i costi dei vari pezzi che sto acquistando, man mano.
Mi piacerebbe arrivare ad avere un’idea, a prototipo realizzato, di quanto è costato complessivamente il progetto, per capire come ottimizzare le spese su eventuali modelli futuri o nell’ipotetico (e remoto) caso di una produzione in mini-serie.

Non c’entra direttamente, ma un’altra cosa che forse toccherà metter su massMakers presto, è un brush di Arduino per l’highliter; potrebbe aiutare quando si condividono sketch online.

Nel prossimo post vorrei affrontare più nel dettaglio la parte per me più complessa, ovvero quella dei motori.

Opendolly

As for Alan, this article will be in Italian only, by now.
Sorry for that, but we’re working on translation features; please keep in touch if you think you might be interested in what we’re saying here.


picture by Martin Roberts

Finalmente anch’io cerco di fare una piccola presentazione del progetto che vorrei proporre e portare avanti (anche) su massMakers, come anticipavo qui.
L’idea in sé non è nulla di originale; si tratta di un Motion Controlled Dolly. Del genere, ne hanno già fatti un’infinità, con varianti e funzionalità d’ogni tipo.

Quello che vorrei cercare di fare io è una sintesi, massimizzando qualità e quantità delle prestazioni e minimizzando i costi allo stesso tempo.
Delle innumerevoli versioni di Dolly che ho visto, ne ho trovate davvero poche di interessanti, sia in termini di portabilità che di facilità d’installazione. Inoltre è raro incontrare (se non su modelli commerciali) dolly che offrano una molteplicità di programmi e di funzioni.

Le caratteristiche che vorrei provare a incorporare nel mio dolly sono:

  • funzionalità timelapse multiprogramma
  • funzionalità stop motion multiprogramma
  • motion control per la rotazione del corpo macchina
  • motion control per la messa a fuoco
  • facilità d’installazione
  • trasportabilità
  • modularità del sistema

Non pretendo di riuscire a coniugare subito tutti questi aspetti ma conto di tenerli a mente da ora, come direzione alla quale tendere per lo sviluppo di tutto il progetto.
Sul piano meramente teorico, con Opendolly dovrebbe esser possibile fare timelapse con carrello e/o cambio dell’angolazione di ripresa  e/o cambio del piano di fuoco, fare stop-motion assistita (è, questo, un concetto ancora vago ma ho delle idee da sviluppare, in merito) e fare carrellate video e/o nodal pan a controllo numerico (per facilitare ad esempio l’integrazione di elementi in CG).

Impostazione generale

Chiaramente, prima di cominciare bisogna avere un’idea delle parti che comporranno il sistema, tanto sul piano tecnico quanto su quello costruttivo (il design, per capirci).

Come anticipavo, già esiste una varietà di esempi più o meno riusciti, più o meno semplici, per fortuna spesso documentati. L’insieme delle informazioni reperibili è più che sufficiente per farsi un’idea dell’esistente.
Di seguito, una prima raccolta di progetti che ho trovato fino ad ora (tutt’altro che esaustiva ma sufficiente per iniziare):

A margine, solo come promemoria, mi sono segnato anche Nikon DSLR tips: 15mm Rig Motion Controlled Timelapse Skater Dolly. E’ tutt’altro tipo di dolly ma non sarebbe male, un giorno, pensare anche a una cosa del genere.

Per il momento, avendo già un carrello Igus, vorrei usarlo come punto di partenza per la prototipazione del dolly.
Mi sarebbe piaciuto costruire il carrello da zero (come nel video di Martin Roberts). Però c’è già molto da fare sul piano tecnico, per cui penso che al momento mi concentrerò su quello e procederò con quel che ho.

A questo punto, le scelte che ho ritenuto prioritarie sono due: come controllare l’otturatore e come controllare il movimento (ovvero, che motore usare).
Per l’otturatore, farò una prima prova con la soluzione più low-tech, ovvero il cavo; ho appena ricevuto (ed aperto) un telecomandaccio da due soldi preso su ebay, da cannibalizzare.
Per il motore, devo ancora capire bene pro e contro delle due alternative, ovvero motori stepper o servo. Per il sistema di trasmissione, invece, sono praticamente certo che opterò per la cinghia dentata.

Comunque parlerò più nel dettaglio di entrambi questi aspetti, nei prossimi post. Presto, spero.

Circular Shift

Hi Massmakers,

I know this is common problem with a very weel solution, for mu step sequencer project I needed a Circular shift buffer, so I just want share whant I’ve just learned

This simple code show a left circular shift

unsigned char c = 1;
for(int i=0;i<64;++i)
{
    if(c & 0x1)
        cout << "init" << endl;
    cout << (unsigned short)c << endl;
    c = (c << 1 | c >> 7);
}

So the magic line is this one:

c = (c << 1 | c >> 7);

What’s going on here?

So if you already know something about bit operators we are shifting C to one bit left, so for example if c is equal to 1001101 the result of the shift operation will be 0011010.

But pay attention, we lost one bit, and here the right shift does the magic. basically if you take 10011101 and shit by 7 bit, the resul will be 00000001, so we’re just moving the last bit to the first position, and with the or operation will put this into the variable C.

This is the circular shift for 8 bit, but if your buffer has a different size, this is the general rule:

var a;
a << 1 | a >> (sizeof(a)*8-1);

Cheers

Mass Sidestepping Manufacture

I just read an article by Core77 which I found interesting, even if it doesn’t apply to the making of electronics, specifically. Nonetheless, it is strictly related to the overall philosophy of massMakers.

The article is about CustomMade, a platform to let people buy custom from local Makers.

Here’s their vision:

Surely, the kind of products you can find on their site is different from what we expect massMakers to deal with.
Also, the way CustomMade intends to build a commerce while bypassing the mass manufacturing, doesn’t share a lot with the non-commercial model we have in our mind for massMakers and, generally speaking, for the future of our development.

What I’d point out here is how CustomMade gives its contribution to the variety of glocalization forms, that are being experimented (and hopefully proved meaningful) presently, around the world.
It’s pretty obvious that it definitely is a growing phenomenon, and seeing it applied in such a variety of ways and contexts is someway encouraging. Yet, we’re pretty far from any substantial, global change.

As a side note, I recently met a colleague and dear friend of mine, with whom I share a lot (in terms of both past experiences and present vision). While speaking with him, I realized for the first time how massMakers’ principles do apply to the broader field of product design (with some obvious restrictions).
It’s probably too early to speak about the chance of incorporating such a wide field into this platform’s domain. I just wanted to leave a note about that possibility, by now.

 

Step Sequencer – Part 1

sorry guys, I will translate this article as soon as I get more time.

Ciao a tutti,

Qui vorrei esporre i miei primi passi nella costruzione di uno step sequencer un po’ particolare, quello che vorrei costruire e’ una via di mezzo tra un monome ed un korg electribe ( per chi non sapesse cosa sono questi due strumenti consiglio una bella occhiata su youtube 😛 ). Pensando un po’ a come costruire il tutto per adesso ho scelto di appoggiarmi ad arduino, in quanto e’ molto facile da programmare. Ma non e’ escluso che con l’aumentare del progetto non si deve passare a qualcosa di più complesso, magari un fpga oppure più microcontroller interconnessi. Vi preannuncio che le mie conoscenze di elettronica sono molto arrugginite per cui molto probabilmente esistono molte altre vie migliori da prendere rispetto a quelle a cui ho pensato, anzi se avete qualcosa da suggerire siete benvenuti.

Ora il primo pezzo e direi anche il piu importante per il nostro step sequencer e’ la matrice di bottoni. Avrei in mente di usare una matrice di 8×8, ma fino adesso sto facendo i test con una matrice 4×4, anche perché ci vuole un po’ a saldare tutti i diodi e i led rgb 😛

I componenti che ci servono sono i seguenti:

Ora veniamo ad un po’ di teoria, ovvero come gestire la matrice di bottoni senza far fuori tutti i pin di arduino e senza usare troppa corrente?

La tecnica e’ abbastanza semplice, in pratica si dà corrente ad un colonna alla volta.

In questo modo quando uno dei pulsanti sarà schiacciato trasferirà il livello logico alto della colonna sulla corrispettiva riga e in questo modo il microcontrollore sapra che bottone è stato premuto

 

Ora però se si costruisce un circuito esattamente in questo modo si avrà un problema quando vengono schiacciati più tasti insieme, questo problema viene chiamato “Ghosting problem”. Infatti prendiamo ad esempio questo caso in cui C2 B2 e B3 sono attivi:

Quando C e’ attivo il micro controller vedrà attiva anche la seconda riga visto che C2 e’ premuto, ma visto che anche B2 e B3 sono attivi vedrà attiva anche la 3a riga per cui penserà che anche C3 e’ attivo!

Per risolvere questo problema si introducono semplicemente dei diodi tra le righe e colonne in modo da direzionare la corrente in questo modo non ci saranno più problemi di ghosting

 

 

Ora abbiamo la nostra matrice perfettamente funzionante però se osserviamo bene c’e’ qualcosa di indesiderato, ovvero già solo per 16 bottoni abbiamo usato 8 pin del nostro microcontroller, per cui per una matrice 8×8 dovremmo usare 16 pin!

Per fortuna qui vengono in aiuto i nostri shift register! Prima di tutto, cosa sono gli shift register?

Gli Shift Register, sono dei componenti costituiti da più celle di memoria e dato un clock in ingresso spostano il contenuto delle celle verso destra o verso sinistra a seconda del tipo di registro. Comunque se volete piu informazioni date uno sguardo a wiki http://it.wikipedia.org/wiki/Registro_a_scorrimento

Nel nostro caso ci serve un registro a 8 bit di tipo SIPO ovvero serial inpunt parallel output che si occuperà di dare corrente ad una colonna alla volta, mentre un shift register PISO verrà usato per leggere i valori sulle varie righe.

Ed ecco qui lo schema del mio circuito:

 

I pin con i numeri che vedete sono i pin del mio arduino mega a cui ho connesso il 164 e il 165. Come vedete dallo schema ho dovuto aggiungere anche una rete di pulldown, questo perché quando non arriva corrente se i pin del 165 fossero flottanti ci potrebbero essere delle letture sbagliate visto che gli input sono indefiniti, per cui bisogna forzarli a massa quando hanno in ingresso un segnale LOW, ed e’ proprio questo che fa la rete di pull down.

Ora che abbiamo tutto connesso veniamo ad un po’ di codice da passare ad arduino. Questa e’ la funzione che ho scritto per fare lo scan della matrice:

 

// Author: Alan Stanzione
// Date: 14 October 2012

int clockPin = 2;
int clearPin = 3;
int aDataPin = 5;

int inClock = 9;
int inClockInh = 11;
int inLoad = 10;
int inData = 12;

int temp = 0;

void scanButtonsMatrix()
{
	for(int i=0;i<8;++i)
	{
		//active column
		digitalWrite(clockPin, 0);
		if(i==0)
			digitalWrite(aDataPin, 1);
		else
			digitalWrite(aDataPin, 0);
		digitalWrite(clockPin, 1);

		//scan row

		digitalWrite(inClockInh , 0); // read into register (tells the 165 to take a snapshot of its input pins)
		digitalWrite(inLoad, 0); // done reading into register, ready for us to read    
		digitalWrite(inClock, 0);
		digitalWrite(inClock, 1);

		// in order to start reading inClockInh and load/shit must go up in the same time
		digitalWrite(inClockInh , 1); 
		digitalWrite(inLoad, 1);

		digitalWrite(inClockInh , 0);

		for(int j=0; j<8; j++)
		{ // read each of the 165's 8 inputs (or its snapshot of it rather)

			// tell the 165 to send the inputs pin state
			digitalWrite(inClock, 0);
			// read the current output
			temp = digitalRead(inData); // read the state
			// tell the 165 we are done reading
			digitalWrite(inClock, 1);
			if(temp==1)
            {
				Serial.println("Button pressed:");
				Serial.print(i);
				Serial.print("x");
				Serial.print(j);
                Serial.println("");
            }
		}
		digitalWrite(inClockHin, 1);
	}
}

void setup()
{
	Serial.begin(9600);

	pinMode(clearPin, OUTPUT);
	digitalWrite(clearPin, 1); // enable output, you could also tie this pin to VCC
	pinMode(aDataPin, OUTPUT);
	pinMode(clockPin, OUTPUT);

	//init 165
	pinMode(inClock, OUTPUT); 
  	pinMode(inData, INPUT);
  	pinMode(inClockHin, OUTPUT);  
  	pinMode(inLoad, OUTPUT);

}

void loop()
{ 
	scanButtonsMatrix();
}

 

Con questo posso chiudere la prima parte, la seconda parte sarà aggiungere e gestire i led rgb con il MAX 7221

Vi saluto con qualche immagine del mio progetto, a presto!

Alan

 

FCRV

Matteo Loglio made Fake Computer Real Violence, at FabLab Torino.
FCRV is a device built using Arduino Leonardo, TinkerKit and an accelerometer; when tilted enough, it sends the “three-finger salute” to your computer.

The whole project and source code is shared here. Though not being serious, that makes much sense in terms of massMakers’ philosophy: openness, trashware, #ManVsData, they all converge in this exquisite piece of hardware.

Via: @mbanzi.

relative openness and hardware

On September the 29th, the Open Hardware Summit took place in NYC.

The MAKE video team asked around thoughts about MakerBot closing off some of its source files. I was someway aware, already, of MakerBot’s new policies in restricting its openness, and of the debate it triggered. But the opinions collected here definitely come from a relevant subset of voices.

I think there are ways for companies to grow and remain open source, but I’m not sure that we know what those ways are, yet

Windell Oskay
Evil Mad Scientist Laboratories

As Bre Pettis (co-founder and CEO of MakerBot Industries) says in the video, a lot has been written on their blog about this issue; but if you want something to start reading from, here you are a hint. If I were you, I’d follow the link you’ll find there too.

Apparently, in the last weeks such debate is getting more and more mature, and it’s revealing important principles and perspectives, when considering realistic (and sustainable) ways to make a business based on openness. Or maybe such a debate is much older and more mature than I might expect, and I’m seeing it arising just now.
Anyway, I’m pretty sure it’s something worth following.

is Hardware the new Yeah?

@mbanzi recently tweeted of an article from TechCrunch which might be arguable, but worths a read (comments included): The Mobile/Social/Local/Cloud Land Grab Is Over by Jon Evans (who’s he? we’ll get a better idea in the future).

Here’s the author ‘s vision:

The last five years of software startups have (mostly) been little more than the shockwave emanating from the big bangs of 2006-07. Now, at last, we can start getting ready for the next eruption.
Because there’s a new one coming. Software continues to eat the world–but I believe the name of the next big boom is hardware.
[…] I found Hardware Alley more interesting than almost all the software startups. The hardware cycle is slower than that of software, so its boom may take ten years to peak, rather than three or four…but it’s coming. My advice is to get in and stake your claim now.

The whole prediction might be a little too one-way, but definitely it’s good sign to us.
Not only we seem to go in the right direction, we also keep continuity between the old and the new world (take this as a hint, if you didn’t figure out what massMakers will be, yet.).
Come on, ain’t it cool?

Arduino Workshop in Rome

The Officine Arduino Team has organized a 2-days workshop in Rome. The program is based on 2 meetings, each one 8 hours long, on the 29-30 Sept. 2012, 10:00 AM to 18:00 PM.

The workshop consists of 16 hours of teaching and is aimed for tinkerers, teachers, curious people, hobbysts, hackers, and anybody who wants to change its approach towards technology.

The workshop is organized together with Cattid– Research centre for Information and Communication Technology of “Sapienza” University of Rome and DiScienza, an italian NGO whose mission is promoting and spreading science all over Italy (cool). They organize an Arduino Day each year in Rome, promoting Arduino’s culture & approach.

For further infos, go to the official page.