Salut arno,
arno wrote: ↑Fri 22 Jun 2018, 22:13
* vous utilisez libopencm3, visiblement sur des STM32. Qu'en avez vous pensé ? Le conseilleriez vous ?
Donc on a libopencm3, effectivement sur des STM32. Par contre on ne s'en sert que pour notre bootloader, et pas dans le code "application" des cartes. Pour cette partie on utilise ChibiOS, qui comprend aussi un ensemble de drivers qui sont bien mieux intégré dans le noyau temps réel. Par exemple, les interrupts et le DMA sont gérés de manière transparente avec ChibiOS, alors que avec libopencm3 c'est beaucoup plus "low-level". Ca accélère pas mal le développement, mais ca augmente aussi la quantité de mémoire flash nécessaire. Vu que notre bootloader doit être le plus lightweight possible, libopencm3 est plus adapté. En conclusion: On trouve que c'est une librairie cool et qui fait bien son boulot, mais on ne s'en sert pas beaucoup
arno wrote: ↑Fri 22 Jun 2018, 22:13
* J'ai vu passer des balises UWB à base de Decawave DW1000. Vous les utilisiez en mode two-way ranging pour entre les robots pour l'évitement ? entre les robots et les balises pour la localisation ? Pour autre chose ? Quels résultats et fiabilité avez vous obtenus ?
T'as l'oeil
En fait on ne s'en sert pas encore beaucoup. Le système marche, on arrive à positionner un robot avec, mais on a des soucis de fréquence de rafraichissement, donc c'est encore en développement on dira. Ceci dit les premiers résultats sont plutôt encourageants et on va bosser dessus cet été et l'année prochaine. J'avais pu faire une partie du projet pour un cours à l'université, j'ai mis le rapport final en pièce jointe. Il contient quelques mesures de performance, et explications sur l'algo.
Par contre on avait mis une balise dans le panneau domotique pour confirmer qu'il s'était bien allumé et détecter si l'adversaire le coupait. On a jamais pu s'en servir, mais ca marchait bien en test
arno wrote: ↑Fri 22 Jun 2018, 22:13
* Dans la présentation du bootloader CAN, vous avez "all (>20) boards". Je crois que c'est un nouveau records ! C'est pour tout l'ensemble robots et balises, où dans un seul robot ?
Alors voilà le détail, par robot on est pile à 20:
- 2 cartes pour la base roulante
- 2 pour les "mains" sur le côté
- Une carte en bout de bras pour mesurer la présence d'un cube
- 3 cartes pour le bras
- 1 carte pour le servo pour tourner le bout du bras pour une tour de 5 (jamais utilisé en match)
- 4 pour le bras
- 4 cartes pour les pompes
- 1 carte pour le canon
- 1 carte pour la balise catadioptre
- 1 carte pour UWB
- 1 carte pour le haut niveau (strat, odométrie, lcd, etc.). Celle ci est pas gérée par le bootloader, vu qu'on a souvent besoin de brancher un debugger.
Mais c'est pas un record, il me semble que en
2016 on était à 32 cartes dans notre grand robot de mémoire
Faut dire que une fois que ton bus marche bien, tu te prive moins pour ajouter des trucs dessus.
Je conseillerais pas forcément l'expérience à tout le monde ca nous a bien pris 3 ans pour avoir quelque chose qui marche bien, et les deux premières années ca ne marchait vraiment pas (pas homologué, puis dernier à la coupe de suisse). Ceci dit si tu peux investir le temps de développement, bah c'est fou la modularité que tu gagne. Par exemple dans le canon on a du rajouter un moteur d'abord, puis un moteur asservi, puis un capteur. Bah sans bus, suivant le niveau de modularité que tu as, ca sera galère.
