risorse | micro:maqueen imit mbot
È possibile programmare micro:Maqueen in modo che si comporti alla stessa stregua di mBot quando inizializzato con le impostazioni di fabbrica (cfr. ”Studio del firmware di mBot”)? Quale ambiente di sviluppo, tra Mind+ e MakeCode risulta più comodo per sviluppare un programma di tale complessità?
Salta direttamente alle conclusioni.
L'estensione «Maqueen» per MakeCode non contiene blocchi per il controllo dei LED RGB del robot. Fortunatamente ne esiste una apposta, «Neopixel». Per poter indirizzare singolarmente i LED è necessario dapprima definire una strip di 4 LED sul pin P15 in formato GBR (micro:Maqueen monta dei LED di tipo WS2812B che, stando alle specifiche, richiedono questo tipo di formato). Occorre infine creare un range di lunghezza 1 per ognuno dei LED:
La mappatura dei 4 LED RGB di micro:Maqueen in altrettanti range.
Fatto ciò, per accendere un singolo LED si utilizza il blocco (…) show color (…) selezionando il range ad esso associato ed il colore desiderato.
ATTENZIONE! L'estensione «Neopixel» è incompatibile col Bluetooth. Come riporta la documentazione ufficiale: “This package disables BLE as the real time requirements of the WS2812 conflict with the BLE stack”.
Avevo già verificato la codifica dei tasti del telecomando di mBot in MakeCode con quella ufficiale (cfr. “mBot vs. micro:Maqueen”), e ho dato per scontato che Mind+ usasse la stessa mappatura. Naturalmente mi sbagliavo: qualunque tasto premessi micro:Maqueen rimaneva impassibile. Ho allora predisposto un programma per determinare i codici che Mind+ assegna ai vari tasti del telecomando:
Il programma Mind+ per la decodifica dei tasti del telecomando.
Lo schema sottostante riporta i codici che Mind+ assegna ad ogni tasto:
I codici numerici associati ai tasti del telecomando I/R di mBot.
Sembra non ci sia alcuna relazione tra i codici utilizzati dai due programmi:
Tasto | MakeCode | Mind+ |
---|---|---|
A | 69 | 93 |
B | 70 | 157 |
C | 71 | 29 |
D | 68 | 221 |
↑ | 64 | 253 |
E | 67 | 61 |
← | 7 | 31 |
⚙ | 21 | 87 |
→ | 9 | 111 |
0 | 22 | 151 |
↓ | 25 | 103 |
F | 13 | 79 |
1 | 12 | 207 |
2 | 24 | 231 |
3 | 94 | 133 |
4 | 8 | 239 |
5 | 28 | 199 |
6 | 90 | 165 |
7 | 66 | 189 |
8 | 82 | 181 |
9 | 74 | 173 |
Se però si cambia base, qualcosa salta all'occhio:
Tasto | MakeCode | Mind+ |
---|---|---|
A | 01000101 | 01011101 |
B | 01000110 | 10011101 |
C | 01000111 | 00011101 |
D | 01000100 | 11011101 |
↑ | 01000000 | 11111101 |
E | 01000011 | 00111101 |
← | 00000111 | 00011111 |
⚙ | 00010101 | 01010111 |
→ | 00001001 | 01101111 |
0 | 00010110 | 10010111 |
↓ | 00011001 | 01100111 |
F | 00001101 | 01001111 |
1 | 00001100 | 11001111 |
2 | 00011000 | 11100111 |
3 | 01011110 | 10000101 |
4 | 00001000 | 11101111 |
5 | 00011100 | 11000111 |
6 | 01011010 | 10100101 |
7 | 01000010 | 10111101 |
8 | 01010010 | 10110101 |
9 | 01001010 | 10101101 |
Le sequenze binarie di Mind+ sono quelle di MakeCode negate e rovesciate, segno che uno dei due ambienti non interpreta nel modo corretto il segnale raccolto dal sensore I/R. Penso si tratti di Mind+, dato che i codici di MakeCode corrispondono a quelli riportati nella documentazione ufficiale.
[Aggiornamento 01/02/2020]
Ho chiesto lumi a riguardo a Mindplus. La risposta è arrivata un paio di giorni dopo:
Hello Gianfranco,
Nothing is wrong, different software handles it differently, just to make the result look easier to operate. You just need to get the value of the case first, and then use the conditions to determine what to do when the value of the infrared remote control is equal to this value. In MinkPlus's MaQueen kit, the last byte of this remote control hex is taken and converted into decimal display.
A corredo del messaggio c'era questa immagine (click per ingrandirla):
Schematizzazione dell'algoritmo di Mindplus che realizza la codifica dei tasti
Il codice assegnato al tasto è dunque l'ultimo byte del pacchetto ricevuto dal telecomando.
Come indicato sul sito ufficiale, il telecomando di mBot adotta l'«IR NEC protocol», le cui specifiche si possono trovare qui. Saltano agli occhi due particolari, qui sotto evidenziati:
When a key is pressed on the remote controller, the message transmitted consists of the following, in order:The four bytes of data bits are each sent least significant bit first.
- a 9ms leading pulse burst (…)
- a 4.5ms space
- the 8-bit address for the receiving device
- the 8-bit logical inverse of the address
- the 8-bit command
- the 8-bit logical inverse of the command
- a final 562.5µs pulse burst to signify the end of message transmission.
Questo spiega definitivamente la difformità nelle due decodifiche: anziché utilizzare il terzo byte, quello che contiene il dato reale, Mindplus prende il quarto, che contiene il dato negato; inoltre non riordina i bit nonostante la posizione in cui si trovano non sia quella corretta:
Il protocollo NEC trasmette i byte a partire dal bit meno significativo
[Aggiornamento 03/02/2020]
Ho fatto presente la cosa a Mindplus, che ha replicato:
yes, The processing methods and results of makecode and mblock and mindplus may be different or the same, because different developers have different ideas.
Penso non sia necessario proseguire oltre nella conversazione.
Nè Mind+ nè MakeCode consentono di interrogare il sensore I/R in modo sicrono; entrambi permettono di eseguire del codice in caso di ricezione di un comando (cfr. blocco when (P16) received [infrared signal] di Mind+ e on IR received [message] di MakeCode). L'estensione «Maqueen» di MakeCode comprende il blocco read IR key, che però fornisce il valore dell'ultimo tasto premuto – non permette quindi di stabilire se in un dato istante nessuno dei tasti del telecomando è premuto.
Con i blocchi a disposizione non è quindi possibile implementare il polling dello stato del telecomando come fa mBot, che si ferma automaticamente quando si rilascia il tasto direzionale che lo ha messo in moto. Per questa ragione ho deciso di assegnare al tasto centrale, quello con l'immagine della ruota dentata, la funzione di arresto dei motori. Attenzione dunque: premendo uno dei tasti direzionali il robot inizierà a muoversi, e continuerà a farlo fino a quando non riceverà il comando di stop.
Nulla di particolare da segnalare nell'implementazione di questo comportamento.
A differenza di mBlock, nè Mind+ nè MakeCode dispongono di un blocco per stabilire lo stato d'insieme del sensore di linea; è dunque necessario interrogare separatamente i due recettori col blocco read […] line tracking sensor comune ai due ambienti di lavoro. In entrambi i casi il valore ritornato è 1 se il sensore si trova su una superficie chiara, 0 se si trova su una superficie scura.
Da segnalare che ad alte velocità il comportamento di micro:Maqueen è tutt'altro che ottimale quando messo alla prova sul circuito di test di mBot; evidentemente il diametro inferiore delle ruote rispetto a quelle di mBot, la carreggiata inferiore e l'interasse maggiore tra i due recettori del sensore di linea – 1.5cm contro 1.3cm – mal si sposano con il raggio di curvatura 1:5 adottato dal programma per mBot.
In MakeCode è possibile creare dei programmi non validi. Mi è capitato per esempio di:
Un programma invalido.
Ci sono vari indizi che avrebbero dovuto richiamare la mia attenzione, uno su tutti il contorno giallo del blocco che contiene l'errore – la variabile strip non esiste più da quando l'ho rinominata. Inoltre, seppur per un breve lasso di tempo, in basso al centro è apparso questo avviso:
Il messaggio d'errore apparso per pochi istanti nella parte inferiore dell'editor.
Non ultimo, l'emulatore in alto a sinistra si è arrestato mostrando una faccina triste:
In caso di errore l'emulatore si blocca.
Ignorando tutto ciò ho caricato il programma sulla scheda. Anziché accendere i LED di Maqueen di bianco, micro:bit ha mostrato sul suo display, in sequenza, una faccina triste, un 9, un 8, un altro 9, per poi ricominciare da capo. Immaginando che si trattasse di una segnalazione d'errore, ho cercato in rete il codice d'errore 989 associato a micro:bit. Sono così giunto alla pagina ufficiale che descrive i codici d'errore di micro:bit, scoperendo che al codice 989 corrisponde l'errore object is null. Da lì è stato facile individuare l'errore e correggerlo.
micro:Maqueen può imitare mBot a patto di modificare la logica di controllo del movimento con il telecomando: mentre mBot si ferma automaticamente quando nessuno dei tasti direzionali è premuto, micro:Maqueen va arrestato con un comando apposito. Non c'è modo, nè in Mind+ nè in MakeCode, di verificare lo stato del telecomando a un dato istante.
Sono disponibili sia il file di progetto per Mind+ che l'immagine binaria pronta per essere caricata su micro:bit realizzata con MakeCode. Per i più curiosi ci sono pure il sorgente C++ prodotto da Mind+ e il codice JavaScript sintetizzato da MakeCode.
Per quando riguarda la dimensione del programma compilato, l'Upload in Mind+ riporta:
The project uses 199136 bytes, occupies (76%) program memory space, leaving 63008 bytes, up to 262144 bytes. Global variables use 8228 bytes, (50%) of dynamic memory, leaving 8156 byte local variables, up to 16384 bytes. upload success
L'immagine binaria scaricata da MakeCode pesa invece circa 680KB.
Infine, ecco come si presentano i due programmi (cliccare sulle immagini per ingrandirle):
Il programma sviluppato con Mind+.
Il programma sviluppato con MakeCode.
Pagina modificata il 27/01/2020