mvitale1989 / pwm_rest Goto Github PK

Potrebbe essere utile modificare il driver in maniera che sia rappresentabile come un thread avente una BlockingQueue su cui ascolta richieste di scrittura/lettura, tuttavia andrebbe pensato un sistema di feedback verso il thread chiamante.
Proposta:

• I2CDriver è un thread che gestisce l'hardware I2C: estende la classe Thread e resta in attesa di messaggi sulla propria BlockingQueue;
• PCA9685Driver è a sua volta un oggetto (o thread, non importa) che farà richieste al driver, ma esclusivamente tramite I2CMessenger
• I2CMessenger è la classe che ogni PCA9685Driver istanzierà per poter comunicare con l'I2CDriver (questo vuol dire che nel costruttore di PCA9685Driver, ci dovrà essere il reference che punta all'oggetto I2CDriver...che a sua volta verrà passato al costruttore di I2CMessenger): questo implementa l'interfaccia Callable per poter fornire risposta asincrona; quando viene richiamato, questo manderà un messaggio sulla BlockingQueue di I2CDriver, dicendogli sia il messaggio da mandare sulla I2C, ma SOPRATTUTTO fornendogli la reference alla propria BlockingQueue!!! In questo modo, quando I2CDriver processa il messaggio ricevuto, sa anche dove deve mandare la risposta!!!!! (in alternativa I2CMessenger può estendere BlockingQueue?)

Sarà in quest'oggetto che dichiarerò quali motori sono presenti nell'installazione, e lui a sua volta gestirà in maniera trasparente il driver I2C e gli oggetti PCA9685 necessari al suo funzionamento. In questo modo dovrò solamente richiamare le funzioni "setAngle" dei motori per poter attuare, e l'oggetto si occuperà del resto.

Ogni motore ha i suoi parametri: è necessario scoprire precisamente quali valori di PWM corrispondono ad una determinata posizione (min o max).
Inoltre sarebbe utile mantenere in memoria la direzione di rotazione del motore.

scrivere istruzioni per la compilazione manuale, per sistemi non-debian (lo script automatizzato presuppone dpkg installato)

Implementare:

• Le funzioni del driver
• Creare una classe rappresentante il PCA9685, includente inizializzazione del chip tramite chiamate al driver ed una funzione di test
• Creare uno script per la compilazione, oppure rendere Make il build tool primario; necessario per la compilazione su ambienti in cui eclipse non è presente

Non è necessario memorizzare nel DB il controller del motore. Dovrebbe servire solamente, in corrispondenza di ogni PCA9685, una collezione ORDINATA di ID motore che corrispondono ad i propri canali. Idealmente dovrei avere la tabella PCA9685 (contenente solo l'indirizzo sul bus), la tabella Servo (contenente un ID e le impostazioni del motore) e la tabella di associazione PCA-Servo (che ideamente contenga l'indirizzo PCA [=la sua chiave primaria], l'ID servo ed il canale all'interno del PCA; insomma questa dovrebbe rappresentarmi l'array ordinato di canali del PCA9685).

correggere, nel file compile.sh, le dipendenze reali richieste per poter compilare il sistema

Tramite il servizio REST deve essere possibile:

• Leggere l'attuale configurazione di installazione (tutti i PCA presenti ed i loro canali) e modificarla arbitrariamente aggiungendo e togliendo PCA e Servi (mappatura: /pca e /servo)
• Controllare i motori presenti (mappatura: /servo)

...vuol dire che probabilmente dovrò aggiungere anche un ulteriore parametro all'oggetto servo, che sarebbe "stato attuale di rotazione". (da 0 ad 1...0 se si trova al minimo di rotazione, 1 se al massimo)