Mike118

Intéressant je ne connaissait pas perplexity! =) 
Limite on pourrait faire un sujet qui présente tous les outils d'IA qui sont disponible =)

Oui au final si c'est un outil qui a accès à internet alors il est fort probable que la réponse ait été directement généré à partir de messages que j'ai posté ( à minima pour la partie vigibot ... ) et ça expliquerai aussi pourquoi j'ai eu l'impression de lire un message que j'aurais presque pu répondre x) 

c'est bizarre qu'il n'y ait même pas un lien vers un site douteux

 

 

Il a été retiré par la modération. 

 

 

"The observation is fascinating. It parallels the concept of the 'Uncanny Valley,' where we, as humans, possess the ability to discern simulants in our midst solely through their textual expressions."  (ChatGPT modified my text(

- ha ha, thanks ChatGPT!

 

I do really find it interesting, that we CAN sense out that someones text is 'generated'.  For now at least, that responses from LLMs are too 'correct' and ultimately fail the Turing Test.

 

Yes this is interesting and frightening ... 

 

 

Si vous souhaitez créer un robot Vigibot, il existe des ressources disponibles en ligne qui peuvent vous aider. La documentation officielle de Vigibot comprend des instructions pour assembler le robot et le connecter à votre smartphone. Il existe également des forums et des groupes de discussion où vous pouvez poser des questions et obtenir de l'aide de la communauté Vigibot.

 

 

ça par contre c'est assez effrayant ... Car normalement Chat GPT n'a pas de ressource pour parler de Vigibot... Cela montre un ciblage assez précis ...
C'est comme si on avait utilisé mes réponses à moi comme source pour "entraîner " ce modèle ... 
Et non je ne suis pas derrière ce message de spam ...

So, you aspire to pursue option A).

Let's delve into this choice:

Do you already have a clear understanding of your application?
If not, this should be your initial focus. Feeling the genuine pain points is imperative; it's the key differentiator when multiple companies operate in the same market.

Once you've identified your application: Can you articulate an MVP (Minimum Viable Product)?
The goal is to swiftly enter the market and establish contact with real clients.
Nothing is more detrimental than investing years in development, creating numerous features, only to realize later that the product doesn't meet the expectations of your prospects.

After defining the MVP, pinpoint the shortcuts you can take and identify the core of your technology, where you can bring the most value = what you will do yourself:
About shortcuts you can :
=> Consider starting with existing robotics bases.
=> Utilize existing software.
=> Alternatively, collaborate with individuals who can assist in these areas. However, my advice is not to place all your eggs in the same basket.
About last points on tip : Clearly define your interface and then enlist different individuals to work on each part with well-defined interfaces.

Then : Create your prototype, test it, promote it, and secure your first clients.

Finaly refine your prototype along the way, learning from any mistakes, and then move on to V2.

At least this is the way I am doing it ...

And if I am a robotics entrepreneur - shouldn't I focus more on Computer Vision (AI identification) and SLAM, vs. building a more robust mobile 'robotic' platform?

 
I believe that as a robotics entrepreneur, you should consider either:

A ) Identifying an application where a robot can bring significant value and then developing a solution that delivers this value. In this case, it's crucial not to overly fixate on the robotic platform or software intricacies. The key is to strike a balance, taking shortcuts where feasible (avoid reinventing the wheel if a solution already exists) and concentrating on aspects truly vital to your application—the factors that contribute real value.

B ) Concentrating on your expertise and offering your services to companies pursuing option A. By doing so, you become one of the essential shortcuts that A-type companies require. Focus on your strengths, whether it's in mechanics, electronics, or software.
As your enterprise grows, you may choose to pursue both A and B, or you can continue enhancing the services you already provide.

At the moment, I am personally following option B, ( and if you want to be a type A, I can help you   ) but I am gradually transitioning towards option A in order to do both A and B. ( so if you want to be a type B I may also work with you )

Of course I guess there are also other options but I don't know them...

Quel sujets voudrais tu voir en live avec Robot-Maker ? =) Et quand ? car le dimanche soir est déjà pris par barbatronic
Cela fait un petit moment que je pense à essayer de faire plus de vidéo ou autre, mais ces temps ci, le temps n'est pas ma ressource la plus disponible =)

Tu veux essayer de faire le quatrième à chenille : https://www.robot-ma...ck-set-481.html

Elles ont une très bonne adhérence. Je serais curieux de voir HAYAI s'exercer contre un robot à chenilles =)

Hello everyone!

We would like to share an update regarding our participation in the French Robotics Cup.

In terms of progress, the end of this year has been very intense, and although we haven't been able to make as much progress as we would have liked, we still have a few points to show you!

Firstly, we continue to refine our mecanum base.

Here is how the current version of the base is assembled and wired:

While we work on the final version of the robot base, we are also improving the localization algorithm and conducting movement tests with the prototype base.

Here are some video footages:

Video showing the robot  on the table:

Robot showing what display the Visualizer tool:

And finally, today is the day we need to submit our scientific project report and communication plan! As "veteran participants" (over 30 years old), we are registered in the "Legend" category and have a few additional tasks, including promoting the event

Here's a preview of our report:

 Mars Attacks! Scientific Project and Communication Plan.pdf   2,35 Mo   26 téléchargement(s)

We hope that among our readers, we can inspire a few people to participate in the Cup next year! =)

We'll be back with more updates soon!
Meanwhile, we wish you all a fantastic 2024!

Bonjour à tous !

Nous souhaitons partager avec vous une mise à jour concernant notre participation à la Coupe de France de robotique.

Du point de vue de l'avancement, la fin de cette année a été très intense, et bien que nous n'ayons pas pu progresser autant que nous l'aurions souhaité, nous avons tout de même quelques points à vous montrer !

Tout d'abord, nous continuons à perfectionner notre base mécanum.
 
Voici comment se monte et se câble la version actuelle de la base :



 

 

 

 

 


Pendant que nous travaillons sur la version finale de la base du robot, nous améliorons également l'algorithme de localisation et effectuons des tests de déplacement avec la base prototype. Voici un aperçu en vidéo :

Vidéo du robot sur la table : 

 
Vidéo de ce que nous voyons sur le visualisateur :


Et pour finir, aujourd'hui est le jour où nous devons rendre notre rapport de projet scientifique et notre plan de communication ! En tant que "vieux participants" (plus de 30 ans), nous sommes inscrits dans la catégorie "Légende" et avons quelques tâches supplémentaires, dont la communication autour de l'événement

Voici donc en avant-première notre rapport :
 Projet scientifique et plan de communication Mars Attacks!.pdf   2,36 Mo   41 téléchargement(s)

Nous espérons que parmi nos lecteurs, nous pourrons motiver quelques personnes à participer à la Coupe l'année prochaine ! =)
Nous reviendrons avec plus de nouvelles bientôt !
En attendant, nous vous souhaitons à tous une excellente année 2024 !

Le code de référence, celui que je montre dans la vidéo à 0'38", est ici : https://www.robot-ma...-test/?p=119892

Dans la ligne qui définit la variable D, à la fin, on peut voir previousError = error;

float PID(){
  static float errorSum, previousError;
  float error = periodTarget - feedback;
  float P = kp * error;
  float I = ki * (errorSum = errorSum + (error * dt));
  float D = kd * (error - previousError) / dt;  previousError = error;
  return P + I + D;
}

Oui on est d'accord ce code est bien correct  


 

Toi, tu fais référence au code qui se trouve plus haut dans le fil, ici : https://www.robot-ma...-test/?p=119805

Mais là également, l'instruction se trouve dans la définition de la variable previous, en static, dans la première ligne.

float pid(float error){
  static float integral, previous = error;
  float P = kp * error;
  float I = ki * (integral = integral + error * dt);
  float D = kd * (error - previous) / dt;
  return P + I + D;
}

Mais pas de souci, au contraire, je te remercie d'avoir jeter un coup d'œil au code.

 

Oui en effet c'est bien à ce code dont je fait référence et justement puisque tu as déclaré ta variable en static le travail " previous = error " ne sera fait uniquement la première fois que la fonction est appelée... 

Pour s'en convaincre il suffit de faire un petit essai tout simple  : 

 

void setup() {
  Serial.begin(115200);
  testStatic(42);
}

void loop() {
  testStatic(10);
}

void testStatic(uint8_t val) {
  static uint8_t test = val;
  Serial.println(test);
}

Tu verras que la réponse sera toujours 42  


Sinon autre point de détail : 

 

 

Et d'ailleurs, si tu trouves un loup dans le code de ce post, https://www.robot-ma...board/?p=120002, je t'en remercie par avance.

 

Je n'ai pas trouvé de problème spécifique dans ton code, mais j'ai une petite remarque qui ne te concerne pas directement, mais plutôt de manière générale toute personne lisant ces lignes : 

Il peut parfois être tentant de regrouper deux ou même trois petites lignes de code sur la même ligne pour réduire le nombre total de lignes pour pouvoir dire "le code est super court, il fait seulement 63 lignes si on exclut les espaces..." Cependant, regrouper deux lignes de code sur la même ligne n'améliore souvent pas la lisibilité.

Pour illustrer davantage ce point, c'est un peu comme si on remplaçait toutes nos variables par a, b, c, d, etc., juste pour dire : "Mon code ne fait que tant de caractères..." Cela ne rend pas le code plus lisible (au contraire, c'est même le principe de l'obfuscation du code).

D'ailleurs, au contraire (et comme tu le fais déjà parfois aussi Oracid), il est parfois préférable de diviser une ligne de code en plusieurs lignes pour améliorer la lisibilité.

En général, il faut trouver un équilibre pour le cerveau humain. 
D'un côté, chaque ligne doit contenir une seule information à comprendre, associée à un commentaire bref. Si le commentaire commence à expliquer plusieurs opérations, il serait judicieux de diviser la ligne en plusieurs lignes.
D'un autre côté, il ne faut pas avoir trop de lignes de code pour permettre au cerveau de comprendre facilement le code dans son ensemble.
Souvent, la création de fonctions avec des noms explicites est la meilleure solution, ce que tu fais déjà (par exemple, la fonction PID()).

Bref une remarque un peu hors sujet, mais j'avais envie de l'écrire quelque part. Peut-être qu'un jour, on déplacera ce message vers un sujet plus adapté.

 Tu sais il y a du monde sur le marché.

 

Oui en effet il y a du monde sur le marché.

Moi aussi je propose un service d'impression 3D avec mes machines sur robot maker et il est très peu utilisé... 
Il dépanne juste de temps en temps mais rapidement le peu de clients qui ont des vrais besoins investissent dans une machine . 

Perso j'ai pas vocation a développer plus ce service... Il est là juste en complément pour dépanner si besoin =) En même temps que commander un capteur tu peux commander le support qui va avec... 

 

 je me demande si je ne vais pas me lancer dans l'activité d'impression 3D pour augmenter mes revenus et aussi parce que je n'arrive pas à évoluer dans mon boulot (apparemment quand on est en production on reste en production dans cette boîte).
 

Loin de moi l'idée de te décourager, au contraire, je suis le premier à essayer d'encourage les makers à vivre de leur passion =) 
Mais c'est pas si facile =) 

Bon courage il en faut ! Et de la persévérance aussi  

Les sharp c'est bien mais c'est une techno qui commence a être sacrément dépassée ... ( Même si ça à l'avantage d'être une simple lecture analogique )

Moi je vous proposerais bien ce genre de capteur : https://www.robot-ma...l53l0x-161.html

Tout petit, fonctionnant en I2C + shutdown ... ( En gros il faut prévoir 1 fils par capteurs en plus de l'I2C si on veut en utiliser plus qu'un seul sur le même bus I2C ... )

Ci joint quelques résultats de tests assez "étranges" avec le lidar LD06 : 

Le setup: LD06->ttl/usb converter->PC

sur le PC : Ubuntu et ROS2, le driver https://github.com/l...ar_stl_ros2.git
la grille de rviz est configuré avec des cellules d'un centimetre

Test 1 : 
Des murs à 8.5cm autour du lidar ( la plaque noir fait 17cm et le lidar est au centre )

Config :

Les mesures

Déjà on a des phénomènes bizarre au niveau de 4 coins, et on a des erreurs de mesure...

Test 2 : 

Même config mais avec quatre entretoises M3 plastique noir qui bloquent le champs du lidar ... 


Les mesures :


On retrouve toujours les éléments bizarre du premier test et on note l'impacte des entretoises ...

Test 3 : 

Avec les murs à 20cm de distance : 


Le résultat : 


Le résultat est déjà mieux ... On comprend un peu mieux la limite de distance donnée à 20cm dans la datasheet du capteur... Mais on remarque quand même des erreurs de l'ordre de 1cm sur les mesures ... 

On a également remarqué que le lidar ne tire pas droit ... le faisceau est incliné ce qui nous fait une mesure " conique " ... 
( => D'où le fait d'utiliser le lidar "à l'envers " dans le cadre de la CFR pour que le faisceau du lidar ne passe pas au dessus des murs qui ne font que 7cm ... ) 

Est ce que le 1cm d'erreur observé est lié à cet angle ? 

( To do : caractériser l'angle et faire plus de tests sur différentes surfaces )
 

(English version here)

Bonjour à tous,

Cette année je participe à nouveau à la coupe de France de robotique, mais cette année je recommence avec une nouvelle équipe composée de 
pat92fr hdumcke (que j'ai tous les deux rencontré lors de la TRR ) et moi même. 
Pat à choisi le le nom de Marst Attacks! en référence au film éponyme, et par ce que le thème de l'année 2024 du règlement de la coupe de france de robotique,  c'est " Farming Mars ". Il a été dévoilé en septembre 2023.

C'est la première participation de pat92fr et hdumcke, (donc oui c'est moi qui les ais embarqué dans ce traquenard, mais oui promis ils sont consentants et non pas séquestré )  par conséquent on repart un peu du début, mais pas comme on est pas des débutant en robotique on va plutôt vite, et comme c'est la première fois qu'on travaille ensemble on prend un peu nos marques =). De plus comme ils sont tous les deux du côté de paris et que moi je suis dans le sud, du côté de biarritz on fait surtout des sessions en distanciels, cela n'aide pas forcément la chose mais ça va on s'en sort bien

Pour faire un peu le point sur là où on en est pour le moment : 

Mécaniquement : 

On part sur une base mecanum avec un lidar positionné assez bas de sorte à taper sur les bordures de la table pour se localiser ( mon expérience avec vigibot ) . Des contre axes sont ajoutés au niveau des roues dans le carrénage de protection pour soulager un peu les réducteur des moteurs et le train moteur avant est monté sur une liaison pivot afin d'avoir les 4 roues toujours parfaitement en contact sur le sol.

Quelques photo : 

La base assemblée vue de dessus : 

La base assemblée vue de face : 

La mise en évidence de la liaison pivot du train avant sans les roues : 

Vu de dessus du support moteur intégrant roulement et contre axe dans le carénage de roues : 


Vu de face du support moteur intégrant roulement et contre axe dans le carénage de roues

Pour cette base mécanum de robot on utilise : 

• 4 moteurs dji m2006 avec leur contrôleur C620
• 1 lot de 4 roues mecanum
• 8 roulements à collerette 8mm

ainsi que plusieurs pièces en imprimées en 3D (PETG) dont les fichiers seront partagées et pas mal de visserie.

Voilà à quoi ressemble l'outil pour le moment : 

 

Cet outil va être partagé avec différents exemple sur le github de l'outil de visualisation:  ( Les exemples de base ont déjà été partagé, l'idée étant de fournir des briques afin que chacun puisse développer l'outil qui lui convient à partir d'exemples )


Côté code du robot : 

Côté code du robot, pour le moment on s'est concentré essentiellement sur le pilotage du robot et sa localisation sur la table. L'ensemble tourne sur un stm32 avec l'envoie des données vers le visualisateur se faisant en wifi avec un esp32.

On a un actuellement un ensemble qui tourne même si c'est pas encore parfait et qui est connecté à notre visualisateur. 

Pendant les tests on obtient pour le moment ce genre de choses :

Dans cette vidéo on a un robot qui se déplace vraiment sur une table et ce qu'on voit c'est ce que le robot envoie comme données. 

Il affiche où il pense être sur la table,  et en rouge on voit les points lidar... 

On peut voir que vers 1min50 le robot touche un obstacle et perds sa localisation... Il faut qu'on travaille la partie la détection des robots adverse, c'est en cours de dev   mais les résultats sont déjà assez intéressant =). 


On a prévu de publier pas mal de choses mais il faut encore qu'on avance donc je vous dit à bientôt pour la suite ! =)
 

 

 

Et par pitié, évite la famille des L298 : c'est des antiquités avec des performances horribles (https://www.st.com/r...asheet/l298.pdf) : à 1A, tu as entre 1.8V et 3.2V de perdu dans le pont en H, à 2A tu peux perdre jusqu'à 4.9V de tension. Toute cette tension est dissipée en chaleur, donc il faut refroidir le L298 (et tu vides inutilement ta batterie).

 

@Mike : pourquoi continuer à vendre un composant aussi antique? (il semblerait qu'il existait déjà au milieu des années 70 (https://forum.arduin...98-age/480905/2), c'est à dire quand mes parents étaient des gosses!)

Je suis d'accord pour dire que le L298 c'est pas le top du top et que c'est pas celui que je recommande le plus, ( d'ailleurs j'en ai à peine 25 en stock sur 3 références ... alors que j'ai plus de 50 pcs sur une seule référence pour d'autres produits de la même famille)  mais c'est un produit qui est moins cher que pas mal d'autre solution,  et "plus costaud " que d'autres solution ( plus costaud que le TB6612fng )  ... De plus il est fournit sur des cartes avec un forme factor intéressant et est présent dans de nombreux tutoriels ce qui en fait un produit demandé ... C'est un peu la loi de l'offre qui s'ajuste à la demande ... 

Par contre d'expérience il est pas si " horrible que tu le dis " ... Pour du 2A il chauffe pas tant que ça ... Il est largement utilisable... Plus utilisable que le TB6612FNG ... 
D'ailleurs sur un projet j'ai fini par remplacer les TB6612FNG qui étaient prévu initialement par des L298 carle client réussissait à suffisamment forcer sur ses moteurs ( qui étaient prévu pour 1A max en condition normale ) et réussissait à cramer le TB6612FNG ... Après remplacement plus de soucis ... 

Bref pour un meilleur rendement et pas trop de courant et pas trop cher il y a des nouvelles références qui marchent bien, mais si tu veux un truc solide, pas cher et que le rendement c'est pas ta priorité N°1 , le l298 a encore selon moi une petite place ... En 70 le matériel fabriqué à cette époque il était encore costaud... Je suis sûr qu'il sera encore utilisé dans 50 ans ce composant ... x)

Après si tu me recommandes d'autres driver de moteur pour la plage de 3A en continue, qui sont costaud est pas cher ( genre 6€ 7€ max ) je suis preneur de référence pour remplacer le L298 ...

Tu peux faire la même chose avec le LD06 que ce que tu fais avec ton rp lidar : 

Tu branches le lidar à ta mega et tu décodes la trame sur ta mega (normalement la librairie lD06 que j'ai donnée plus haut fonctionne avec la mega, hésite pas à faire un retour ) puis tu filtres les données et tu envoies en usb juste les données qui te conviennent ... ( comme ce que tu faisais avant ... )