566 réponses à ce sujet

[Keuronde]

Côté classement, c'était un peu la loose, nous n'étions clairement pas prêt. Si nous avons bien progressé sur la partie mécanique, tout ce qui est "core" - déplacement, localisation, détection de l'adversaire, etc... - n'a pas bougé par rapport à l'an dernier, ou que très peu.
Pour les aimants, comme le dit Elfline, ce sont des aimants permanents, ils sont avancés ou reculés par des servomoteurs...

[Keuronde]

Tardivement, nous tenons à exprimer notre reconnaissance. Cette coupe a été, encore une fois, un moment magique pour nous. Cette magie n'aurait pas opéré sans :

Supelec Lyon qui nous a trouvé un Raspbery pi pico au milieu de la nuit, au fond de leur carton pour remplacer celui qui venait de se faire amputer son connecteur.
Lab Sciren, qui nous a fourni une perceuse, pour la seconde année consécutive !

Nos voisins (AZBot, Mars Attack, PM robotics, Les karibou, TDS, Stonkindustrie, MIAM Robotique), tous ceux qui sont passés nous voir à notre stand, pour discuter, échanger... Je pense à Projet & Tech, aux arbitres, à Noxant qui scanner le robot avec leur caméra infrarouge - petit regret de ne pas avoir pris une image ou deux...

Notamment Mars Attacks qui nous a aidé à y voir plus clair sur nos problèmes de servomoteurs.

Ceux qui nous font rêver : Stonkindustrie, TDS team, RCVA, MIAM Robotique, Les Karibous, 7Robots...

Tous ceux qui nous ont soutenu pendant les matchs, nous entendons des "Allez Pooivrooon" sur nos vidéos, et vous n'avez pas idée à quel point ça nous fait chaud au c[U+0153]ur.

Tous les bénévoles présents le jour J sans qui la coupe n'aurait pas lieu, et ceux qui se démènent dans l'ombre toute l'année !

Nous avons adoré :
- La nouvelle présentation / organisation des matchs qui est bien plus dynamique à regarder et diminue grandement l'attente en arrière scène !
- Le restobot qui n'a pas changé, toujours aussi bon !
- Les pains au chocolat - tout chaud - le matin
- Ceux qui ont réalisé que le bois, c'était bien ! Et qui n'ont pas hésité à venir demander de l'outillage...

[Keuronde]

Voici le premier de nos trois articles sur le déroulement de la compétition :
https://poivron-robo...eparation .html

[Keuronde]

Je regarde ça en détail, c'est quand même proche des technologies qu'on utilise ! (sauf pour le machine learning...)

[Keuronde]

Voici le récit de notre participation à la coupe de France de Robotique , pour ceux qui aiment la lecture !
https://poivron-robo...mpetition .html

[alf@]

[Keuronde]

Merci pour la photo !

[alf@]

[Keuronde]

On joue avec les PAMIs cet été ?

premiers_contournements_1M.mp4   3,04 Mo

[Keuronde]

Merci d'avoir pris le temps de lire ma prose !
L'asserv que je propose est inspiré d'un système de pilotage de miroir pour déplacer un faisceau laser, avec une boucle fermée (jusqu'à l'asserv en position) et une boucle ouverte au niveau du trajet
J'ai vraiment eu du mal entre vitesse et trajectoire. Utiliser une trajectoire sans le contrôle en vitesse, j'avaos peur que ce soit vraiment moche.

Pour Vmax centrifuge, je defini une vmax pour chaque trajectoire, que j'ajuste si le robot dérape trop. Tu as une méthode plus élégante ?

Je suis curieux quand tu parles du système de nuée de petits robots... C'est quoi ces robots ? Qu'est ce qui change dans l'asser ?
Je me note de rajouter des précisions sur les acc/décélération max
Je décris ce problème, mais en commençant par parler de l'angle dans la partie "La difficulté de l'asservissement polaire"

Tu penses qu'il faudrait reprendre ce bout ?

[Keuronde]

@Wix [Girafes] (Legend) J'ai bien noté tes retours, je vais finit mes brouillon et quqand je mettrais en forme le code, je verrais si j'ai des trucs plus sympa/coherant en inversant trajectoire / contrôle en vitesse

[Keuronde]

C'est complètement ahurissant ! Qu'il y ai un écart entre le python et le SDK, ok. Mais le compilateur devrait faire sauter les écarts entre l'ide arduino et le SDK.

En tout cas, ces résultats sont très intéressant !

[Keuronde]

Ce serait cool, faudrait en faire un article, mais ces derniers temps, j'ai trop de choses dans la todo list
Enfin un texte rapide avec tes graphs et tes données, ça peut se faire vite !

[Keuronde]

Faudrait voir le code, le temps bas doit comprendre le temps de rebouclage :
C'est un point qu'on avait abordé ici :
https://discord.com/...614141650141195

[Keuronde]

Je viens de finir les inscriptions pour nos équipes :
- Riombotique
- Riombotique Junior
Il n'y aura pas de Poivron Robotique cette année, pas de robot un peu loufoque, 100% bois mais nous restons dans les parages !

[Keuronde]

@Armand [FrWA/E.S.C.RO.C.S]
Sur la vitesse des IO, j'ai repris mes vénérables PIC18F4550 (ils ont piloté nos robots de 2010 à 2022).
On est sur de la bête de course : architecture 8bits, ROM 32ko, RAM 2k.
|| Il a droit a un quartz de 20 MHz, il divise sa fréquence par 5 pour obtenir 4MHz qui alimente une PLL qui augmente la fréquence à 96Mhz et qui la divise par 2 pour le CPU - ouai, c'est un chouïa pas simple||
Dans ma configuration, leur fréquence d'horloge est de 48MHz, il leur faut 4 cycles pour exécuter une instruction, donc on est à 12 Mhz au niveau des instructions.
Je viens de prendre une mesure avec un code de ce type là :
```C
void main(void)
{
// LED en sortie
TRISBbits.TRISB3 = 0;
while ( 1 ) {
LATBbits.LATB3 = 1;
LATBbits.LATB3 = 0;
LATBbits.LATB3 = 1;
LATBbits.LATB3 = 0;
LATBbits.LATB3 = 1;
LATBbits.LATB3 = 0;
}
}
```
Je calcul une fréquence du signe (sur les 3 impulsions) à 5,95 MHz. Donc on est vraiment à 1 instruction par cycle !
Et si on compare ça à l'ESP32 (240MHz) où tu mesures autour de 600kHz, j'ai juste envie de dire :

**C'était mieux avant !**
Et même si ce n'est pas directement la performance de la puce, le temps de compilation n'a rien à voir :
```
$ make clean
$ date; make flash; date
sam. 18 janv. 2025 21:37:36 CET
/opt/microchip/xc8/v2.10/bin/xc8-cc -c -mcodeoffset=0x2000 -mcpu=PIC18F4550 -o build/TestDeLaCarte.p1 TestDeLaCarte.c
/opt/microchip/xc8/v2.10/bin/xc8-cc -mcodeoffset=0x2000 -mcpu=PIC18F4550 -o build/TestDeLaCarte.hex build/TestDeLaCarte.p1

Memory Summary:
Program space used 116h ( 278) of 6000h bytes ( 1.1%)
Data space used 6h ( 6) of 800h bytes ( 0.3%)
Configuration bits used 0h ( 0) of 7h words ( 0.0%)
EEPROM space used 0h ( 0) of 100h bytes ( 0.0%)
ID Location space used 0h ( 0) of 8h bytes ( 0.0%)
Data stack space used 0h ( 0) of 7A0h bytes ( 0.0%)

mv build/TestDeLaCarte.hex dist/TestDeLaCarte.hex
sudo commun/mphidflash-1.7-linux-64 -w dist/TestDeLaCarte.hex
USB HID device found: 24576 bytes free
Device family: PIC18

Erasing...
Writing hex file 'dist/TestDeLaCarte.hex':......
Verifying:......
sam. 18 janv. 2025 21:37:39 CET
```
Oui, **3 secondes pour compilation et flashage** de la puce (sur un intel i7 de 2012) - Tiens, je vais faire la même mesure sur le Rapberry Pi Pico
Et peut-être sur un ESP avec Arduino si je suis d'humeur sadique ce soir
Avec un Raspberry Pi Pico, je note deux choses :
1) la première compilation : ** 18 secondes **
2) une compilation où seul le main.c a changé : ** 2 secondes **
Alors, c'est pas trop mal...
Avec un ESP32 avec l'IDE Arduino, je note aussi deux choses :
1) la première compilation : **45 secondes**
2) une re-compilation où rien n'a changé : **25 secondes**

Sérieusement ?

[Keuronde]

J'ai sorti mon ESP32 et l'ordre de grandeur semble comparable à celui que tu donnes !
Je suis étonné qu'en ESP-IDF, on ne monte pas plus haut...
Mais ma conclusion, c'est "Bloatware"
(après es-tu sûr du 240 MHz ? Pour le Rapsberry Pi Pico, il est annoncé à 133MHz, mais sa fréquence par défaut, c'est 125MHz - et je n'avais trouvé cette info que sur le forum Raspberry Pi https://forums.raspb...ic.php?t=302191 - jamesh, sur ce forum est une valeur sûre )
Tu as utilisé quelle fonction avec ESP-IDF ? gpio_set_level ?

[Keuronde]

Je viens d'essayer avec ça - mais dans l'IDE arduino :
```C
#define LED D6

void setup(){
pinMode(LED,OUTPUT) ;
}
void loop(){
gpio_set_level(GPIO_NUM_21, HIGH) ;
gpio_set_level(GPIO_NUM_21, LOW) ;
gpio_set_level(GPIO_NUM_21, HIGH) ;
gpio_set_level(GPIO_NUM_21, LOW) ;
gpio_set_level(GPIO_NUM_21, HIGH) ;
gpio_set_level(GPIO_NUM_21, LOW) ;
}
```
J'observe un x2 en terme de vitesse par rapport à digitalWrite
(comme toi)
Et là, je tente un accès direct au registre...
J'ai un truc qui tourne avec un accès plus direct aux registres, j'ai un peu galéré...
Du coup, le code n'est pas super propre.
```C
#include "soc/gpio_struct.h"
#define LED D6

uint32_t pin = 0xFFFFFF;
void setup(){
pinMode(LED,OUTPUT) ;
pinMode(D0,OUTPUT) ;
}
void loop(){
GPIO.out_w1ts.out_w1ts = pin; // s: Set (mettre à 1)
GPIO.out_w1tc.out_w1tc = pin; // c: Clear (mettre à 0)
GPIO.out_w1ts.out_w1ts = pin; // s: Set (mettre à 1)
GPIO.out_w1tc.out_w1tc = pin; // c: Clear (mettre à 0)
GPIO.out_w1ts.out_w1ts = pin; // s: Set (mettre à 1)
GPIO.out_w1tc.out_w1tc = pin; // c: Clear (mettre à 0)
}
```
Je monte à 4,46 MHz sur un ESP32C3 - ça me parait lent
(j'arrête pour ce soir, je n'arrive pas - avec un ESP32C3 à 160MHz - à piloter mes E/S plus vite qu'avec un PIC18F4550 avec un Quartz à 20 MHz )

[Keuronde]

Alors, oui, sur le PIC18f4550, le tampon de sortie de la broche est sur le bus de RAM, du coup c'est rapide

Pour l'ESP32, je ne sais pas non plus comment c'est fait, mais ça me surprendrait que ça prenne plus d'un ou de cycle...
(en cherchant, je suis tombé sur cet article qui ressemble bcp à ce dont on discute ici : https://www.instruct...m/Faster-ESP32/)
Mais il ne depasse pas 5 MHz
Caché derrière un certificat invalide : https://bbs.esp32.co...pic.php?t=27963

qui donne un lien vers la doc : https://docs.espress...dedic_gpio.html

En gros, c'est faisable, mais ça nécessaire de :
1) Créer un groupe de GPIO
2) de le piloter en assembleur

Ça commence à devenir pas très drôle

[Keuronde]

J'ai mis un truc dans #riombotique au sujet des PAMI