Ciao Rino,
quando si sviluppa su queste piattaforme , ci sono due esigenze :
la prima e' quella di portare sempre piu' in la l'asticella delle prestazioni e delle funzionalità avanzate.
La seconda che e' quella di consolidare e stabilizzare le versioni piu' vecchie per garantire affidabilità a chi deve volare.
E' un po' come nella formula 1 , ci sono i test dei motori ultra potenti , che danno la prestazione , ma magari saltano dopo un giro di pista e quelli depotenziati che poi si usano in gara per essere sicuri di arrivare in fondo.
Ora noi stiamo lavorando su tutte e due le strade ovviamente per aver sistemi opensource sempre piu' performanti ed affidabili , dando evidenza in modo trasparente di quali sono le criticità e dove stanno in modo tale da consentire alla community di aiutarsi nel migliorare le prestazioni delle nostre macchine.
nella versione 3.1.3 abbiamo provato a tirare il collo ai sensori facendoli leggere a velocità molto piu' alte delle precedenti in modo tale da avere prestazioni assolute piu' elevate rispetto alla versione prcedente , sappiamo che questa cosa puo' mettere in crisi il software e ora stiamo cercando di approfondire su questa versione quale componente venga messa in crisi .
A mio parere conoscendo i limiti di alcune scelte tecnologie fatte in passato , uno degli elementi critici potrebbe essere il magnetometro che viene letto in i2c , il bus i2c purtroppo e' un bus che non mi piace , non propriamente professionale , ma su cui in passato diversi costruttori hanno puntato per avere oggetti semplici da gestire ... in particolare oggetti molto buoni come ad esempio il magnetometro usano il bus i2c , solo quest'anno finalmente i progettisti dell'HMC5883 hanno capito che forse era meglio mettere a disposizione un magnetometro con BUS SPI , ora ne abbiamo gia' recuperati alcuni e stiamo iniziando a fare le prime prove .
In particolare ci piacerebbe per aumentare le prestazioni dei nostri sistemi e anche l'affidabilità cambiare il magnetomtero da i2c a SPI , sulla ver 4.5 e' gia' possibile perche' sul connettore anteriore per la imu e' disponibile l'spi aggiuntiva su cui poter andare a collegare anche il nuovo magnetometro , stiamo lavorando ai driver e spero presto di poter fare anche questo tipo di tetst.
Nel frattempo per poter rendere piu' affidabile anche la 3.1.3 stiamo lavorando sui driver di seriale i2c e usb per vedere di ottimizzare ulteriormente quella versione di codice ... potrebbe essere necessario in futuro tornare indietro su scelte di performance per la versione "affidabile" vedremo ... intanto ringraziamo tutti i dev per i feedback che ci stanno dando sull'affidabilità della versione alpha in modo tale da avere notizie sufficienti per poter migliorare il codice e renderlo affidabile.
Ovviamente se poi volete provare le prestazioni in volo del codice tenete presente gli eventuali limiti .. che in questo momento mi sembrano un paio di ore medie di funzionamento senza interruzioni , sarebbe utile verificare se in modalità automatica , tipo in rtl o loiter cmq vengono riconfermate .
Io questa notte ho lasciato accesa la scheda disarmata con la vers 3.1.3 per 7 ore senza rilevare alcun freeze ... alimentandola da bec ... con gps interno collegato ...
Considerando il tipo di impiego su drone a livello sperimentale se i tempi di volo si attestano attorno ai 30 min medi la percentuale di volte in cui si potrebbe presentare il problema dovrebbe essere assai limitata se non nulla . In questo momento non abbiamo attivato lo watchdog sulla vrbrain anche se supportato perche' se sugli aerei potrebbe funzionare senza grossi problemi ... il restart in aria si puo' prevedere ... sui nostri multicotteri e' improbabile un restart della cpu in volo ... perche' anche pochi secondi di fault potrebbero essere fatali.
Ma mi chiedo su altre piattaforme qualcuno di voi ha mai fatto test simili ?
un saluto
Roberto Navoni
quando si sviluppa su queste piattaforme , ci sono due esigenze :
la prima e' quella di portare sempre piu' in la l'asticella delle prestazioni e delle funzionalità avanzate.
La seconda che e' quella di consolidare e stabilizzare le versioni piu' vecchie per garantire affidabilità a chi deve volare.
E' un po' come nella formula 1 , ci sono i test dei motori ultra potenti , che danno la prestazione , ma magari saltano dopo un giro di pista e quelli depotenziati che poi si usano in gara per essere sicuri di arrivare in fondo.
Ora noi stiamo lavorando su tutte e due le strade ovviamente per aver sistemi opensource sempre piu' performanti ed affidabili , dando evidenza in modo trasparente di quali sono le criticità e dove stanno in modo tale da consentire alla community di aiutarsi nel migliorare le prestazioni delle nostre macchine.
nella versione 3.1.3 abbiamo provato a tirare il collo ai sensori facendoli leggere a velocità molto piu' alte delle precedenti in modo tale da avere prestazioni assolute piu' elevate rispetto alla versione prcedente , sappiamo che questa cosa puo' mettere in crisi il software e ora stiamo cercando di approfondire su questa versione quale componente venga messa in crisi .
A mio parere conoscendo i limiti di alcune scelte tecnologie fatte in passato , uno degli elementi critici potrebbe essere il magnetometro che viene letto in i2c , il bus i2c purtroppo e' un bus che non mi piace , non propriamente professionale , ma su cui in passato diversi costruttori hanno puntato per avere oggetti semplici da gestire ... in particolare oggetti molto buoni come ad esempio il magnetometro usano il bus i2c , solo quest'anno finalmente i progettisti dell'HMC5883 hanno capito che forse era meglio mettere a disposizione un magnetometro con BUS SPI , ora ne abbiamo gia' recuperati alcuni e stiamo iniziando a fare le prime prove .
In particolare ci piacerebbe per aumentare le prestazioni dei nostri sistemi e anche l'affidabilità cambiare il magnetomtero da i2c a SPI , sulla ver 4.5 e' gia' possibile perche' sul connettore anteriore per la imu e' disponibile l'spi aggiuntiva su cui poter andare a collegare anche il nuovo magnetometro , stiamo lavorando ai driver e spero presto di poter fare anche questo tipo di tetst.
Nel frattempo per poter rendere piu' affidabile anche la 3.1.3 stiamo lavorando sui driver di seriale i2c e usb per vedere di ottimizzare ulteriormente quella versione di codice ... potrebbe essere necessario in futuro tornare indietro su scelte di performance per la versione "affidabile" vedremo ... intanto ringraziamo tutti i dev per i feedback che ci stanno dando sull'affidabilità della versione alpha in modo tale da avere notizie sufficienti per poter migliorare il codice e renderlo affidabile.
Ovviamente se poi volete provare le prestazioni in volo del codice tenete presente gli eventuali limiti .. che in questo momento mi sembrano un paio di ore medie di funzionamento senza interruzioni , sarebbe utile verificare se in modalità automatica , tipo in rtl o loiter cmq vengono riconfermate .
Io questa notte ho lasciato accesa la scheda disarmata con la vers 3.1.3 per 7 ore senza rilevare alcun freeze ... alimentandola da bec ... con gps interno collegato ...
Considerando il tipo di impiego su drone a livello sperimentale se i tempi di volo si attestano attorno ai 30 min medi la percentuale di volte in cui si potrebbe presentare il problema dovrebbe essere assai limitata se non nulla . In questo momento non abbiamo attivato lo watchdog sulla vrbrain anche se supportato perche' se sugli aerei potrebbe funzionare senza grossi problemi ... il restart in aria si puo' prevedere ... sui nostri multicotteri e' improbabile un restart della cpu in volo ... perche' anche pochi secondi di fault potrebbero essere fatali.
Ma mi chiedo su altre piattaforme qualcuno di voi ha mai fatto test simili ?
un saluto
Roberto Navoni
Commenta