BeagleBone Black

[matty]

In attesa che il corriere mi consegni il nuovo giocattolo, una BeagleBone black, ero curioso di sapere se qualcuno ha già esperienza con questa scheda (o la precedente BeagleBone 'white'). Qualcuno ha già utilizzato questa scade nell'ambito della robotica (amatoriale)?

[astrobeed]

Orginalmente inviato da matty

Iero curioso di sapere se qualcuno ha già esperienza con questa scheda (o la precedente BeagleBone 'white'). Qualcuno ha già utilizzato questa scade nell'ambito della robotica (amatoriale)?

Tra due secondi arriva Raffaello e ti sommerge di esperienza con la BBB
Scherzi a parte è una buona scheda Linux Embedded, Raffa è riuscito a metterci sopra un nodo ROS, e non è facile da fare.
Io preferisco la Cubieboard alla BBB, sopratutto se è la v2 che ha il processore dual core

[guiott]

Io la sto usando per questo progetto nel quale inizialmente usavo una Aria G25 che ho poi sostituito con la BBB.

In particolare sto usando node.js per colloquiare con la GUI in HTML5 (tramite web socket) e con le schede di navigazione e controllo a basso livello tramite seriale secondo questo schema

Il risultato è questo

[matty]

Wow, un dual core con 1 GB di RAM non è mica male interessante anche per il fatto che è possibile collegare nativamente un disco SATA.
Io pensavo di usare Python come linguaggio di scripting per la programmazione iniziale. Andrà a sostituire un'Arduino 2. ROS non l'ho mai usato, ma mi hai fatto venire una forte curiosità ora...

[matty]

Orginalmente inviato da guiott

Io la sto usando per questo progetto nel quale
In particolare sto usando node.js per colloquiare con la GUI in HTML5 (tramite web socket) e con le schede di navigazione e controllo a basso livello tramite seriale secondo questo schema

Ciao Guido, ho visto il tuo schema ed ora mi sorge un dubbio. I miei intenti erano quelli di utilizzarla come alternativa all'Arduino, ma nel tuoi schemi vedo che la usi in modo coordinato con due DSNav + un Low Level Supervisor. E' una scelta voluta o la BBB è stata inserita dopo nello schema?
Nelle mie intenzioni la BBB dovrebbe gestirmi 4 motori tramite PWM con relativi encoder + comunicazione tramite bus CAN. Voglio strafare con una sola scheda?

[guiott]

La scelta è voluta e pensata accuratamente.
Ho già espresso le mie idee in questo post e ne sono fermamente convinto.

Non fai un PID a 1ms con una scheda con OS non real time e forse neanche con un RTOS (nel quale lo slice è difficilmente inferiore a 1ms), soprattutto mentre sta servendo altri servizi pesanti come publicare un web server e dei servizi web pocket. Nella mia configurazione inoltre c'è anche una IMU (collegata intimamente con le motor controller) che esegue molti altri calcoli sui dati dei sensori in tempi non compatibili con i tempi di risposta di un OS qualsiasi, neanche girasse sotto un 16 core a 3GHz

C'è qualcuno che ha fatto questo però, come vedi, usa le PRU della BBB programmate in assembler. In pratica sono delle periferiche real time collegate con il processore principale.

Guarda caso qualcuno si è inventato anche questo.

[matty]

Ciao Guido, grazie per la risposta. Mi prendo il tempo debito per analizzare tutte le problematiche che hai posto. Il mio intento era di utilizzare un RT Linux, ma sinceramente devo ancora avventurarmi nel relativo tuning.
E' più complicato di quello che pensavo

[astrobeed]

Orginalmente inviato da matty

Il mio intento era di utilizzare un RT Linux, ma sinceramente devo ancora avventurarmi nel relativo tuning.

RT Linux è fuffa allo stato puro, non è possibile far diventare real time un OS che nasce per non esserlo.
In tutti i casi anche se sulla BBB ci metti un vero RTOS (=$$$) te lo scordi lo stesso di controllare il low level.
Queste schede vanno bene per l'high level come gestire delle Webcam, un webserver, ma anche per la mappatura del territorio ad alta risoluzione, pianificare percorsi e tante altre cose, però tutte quante non legate alla gestione real time delle periferiche.
In pratica un sistema di questo tipo è sempre composto da una board Linux embedded abbinata a una, o più, mcu 8/16 bit che gestiscono direttamente l'hardware.

[guiott]

Domandina semplice semplice:
è più veloce un AVR a 8bit @16MHz o un Intel x86 a 32bit @400MHz?

Non vi precipitate. Leggete prima questo:

The GPIO output pins on Intel® Galileo are provided by an I2C Port Expander that is running at standard mode (100 kHz). Each I2C request to update a GPIO requires approximately 2ms. In addition to software overhead, this restricts the frequency achievable on the GPIO outputs to approximately 230 Hz.

Preso da qui.

e questo:

I'm really interested in the horsepower galileo can provide, but at face value i worry that the GPIO is still way behind an ancient 8-bit AVR...

preso da qui.

Dove, in compenso, è anche spiegato come raggiungere, solo su alcuni pin, velocità maggiori.

Quando io rispondo a quel tipo di domande con: "dipende da cosa ci devi fare", molti si inc...quietano. Vorrebbero quella risposta secca ed univoca che molto spesso non si può dare.

[astrobeed]

Orginalmente inviato da guiott

Quando io rispondo a quel tipo di domande con: "dipende da cosa ci devi fare", molti si inc...quietano. Vorrebbero quella risposta secca ed univoca che molto spesso non si può dare.

Infatti è impossibile dare una risposta univoca, se con il sistema Linux embedded devi controllare dei relè, dei led, leggere una tensione ogni tanto, rilevare se un pulsante viene premuto non c'è problema farlo tramite i vari GPIO di queste schede.
Per contro se è necessario azionare dei device con tempistiche minori di 0.1 secondi, controllare motori, peggio ancora leggere un encoder, ma anche gestire dei sensori mems, etc, la cosa può diventare sia molto critica che impossibile.
Ovviamente è possibile utilizzare mcu di fascia alta con core ARM Cortex Mqualcosa per gestire il low level, magari combinando il lavoro di due, tre, mcu ad otto bit su una sola.