Sandro

Have you checked that it is not just due to some perspective effects? (I don't think so, but it's hard to be sure from the video)

Also, I think that if you want to really study the trajectory, you should try to attach your leg in a more stable manner (I think you get significant error just from the trembling).

Otherwise, I think any of your guesses is possible.

To check, I would suggest :

A) get a stable fixation for your leg, so results are reproductible

B) redo the same trajectory : if you get something significantly different, then either your servos or your assembly is quite unstable. If you get the same trajectory, go to C

C) do again the qualibration of the servos : if your trajectory is different, then your calibration is not precise enough. If you get the same trajectory, then go to D

D) change the motors (and recalibrate) : if the trajectory changes, then the motors are probably not very accurate (ie they don't move exactly by the amount they are supposed to, it might be a low quality potentiometer inside for example). If you still get the same trajectory, then it's either the lenght of your parts, or your code that is wrong.

Affiner les paramètres du PWM par potentiomètre, pourquoi pas, mais ça présente la difficulté de pouvoir reproduire le réglage.

Après, si tu veux faire du suivit de ligne ultra rapide (et pas juste rapide) avec des virages serrés (ie assez pour ne pas pouvoir les passer à vitesse max) avec une caméra pour anticiper la ligne, alors je ne suis pas sûr qu'un contrôleur PID soit le plus adapté. Des contrôleurs que je connais, celui qui me semblerait le plus adapté serait un contrôleur par modèle prédictif (ie un contrôleur qui "simule" la position à t+delta_t pour tous les paramètres possibles, et choisit la meilleure combinaison, ie le plus loin devant sans trop d'erreur par rapport à la ligne et à l'orientation de la ligne). NB : j'ai rapidement vu ça en cours, mais j'ai pas vraiment d'expérience dans ce type de controleur.

Mais je penses que déjà avec du PID, on peut faire de belles choses.

 

= mettre une résistance de pull down sur la gate

J'avais interpréter ton message comme souder une résistance de pull-down (mais peut-être que j'ai mal interprété), alors que ma suggestion était de placer une pull-down provisoire sur le header destiné à la Teensy pour confirmer que le seul problème est que la gate est flotante (donc la pull-down ne sera probablement pas indispensable une fois la Teensy présente et le pin en output.

Mais oui, l'idée de fond est la même (et peut-être que c'est moi qui ai mal interprêté ta réponse, et que tu suggérais exactement la même chose que moi)
 

Pour la diode roue libre, elle est fortement recommandée pour les charges inductives (solénoïde, électro-aimant, moteurs, convertisseurs à base de transfo ou d'inductance, ...). Le problème d'une inductance, est que le courant à "du mal" à changer. Tout changement de courant génère une tension U=L*di/dt. Si le changement est très rapide, alors dt est tout petit, donc la tension est énorme. Si la coupure est instantanée, alors la tension est "infinie". En pratique, si on n'offre pas de chemin alternatif au courant, alors la tension monte jusqu'à ce qu'elle suffise pour créer un chemin (en grillant un composant, en passant à travers un "isolant", ou en créant un arc électrique). Bref, ça fini mal. La diode roue libre donne un chemin à ce courant (qui vas tourner "en rond" entre la diode et l'inductance, dissipant l'énergie dans la diode). NB : une résistance à la place de la diode marcherait aussi, sauf qu'elle consommerait du courant en permanence, ce qui n'est pas dommage, et elle est moins adaptée à garder la tension faible.

À noter qu'en soit, un MOSFET a une diode "parasite" interne qui peut faire office de diode roue libre. Mais vue que c'est une diode parasite, elle n'a pas de très bonne caractéristiques, et n'est pas toujours capable de supporter tout le courant. Donc tant qu'on n'est pas sur de la production de masse, c'est en général plus simple d'ajouter une diode que d'essayer de déterminer si la diode interne suffit ou pas.

Pour des charges résistives ou capacitives, la diode roue libre n'apporte rien, mais ne gène pas non plus. Sauf si tu pars dans les extrêmes soit en fréquence (à haute fréquence, la capacité parasite de la diode peut devenir gênante) soit en très très basse consommation (le courant de fuite peut devenir non négligeable). Mais ces cas extrêmes correspondent à des circuits beaucoup plus avancés, donc tu n'as pas à ton soucier pour l'instant.

Bonjour,

En soit, n'importe quelle batterie (NiMh, Li-ion, LiPo, ...) peut être chargée en place (nb : si la ventilation est mauvaise, il faut s'assurer que la recharge est assez lente pour éviter la surchauffe).

Après, tu as 2 options pour recharger un ensemble de batteries en série (des batteries en parallèles peuvent être considérées comme une seule batterie plus grosse) :
1) Recharge avec 2 fils (+ et -) : si tu as 2 batteries/cellules ou plus en série, alors ça t'oblige à avoir un système de gestion de charge (BMS) intégré dans ton robot (il est déjà intégré dans certaines batteries, sinon il faut l'ajouter toi). Ce BMS s'assure d'éviter une surcharge, et d'équilibrer la tension des cellules (=batteries individuelles). Sans équilibrage, la tension totale sera bonne, mais certaines cellules seront surchargées, et d'autres sous chargées, ce qui mène rapidement à la destruction des cellules
 

2) Recharge avec N+1 fils pour N cellules en séries (souvent 2 gros fils et les autres plus fins) : ça permet au chargeur de mesurer la tension de chaque cellule, et de les re-équilibrer si besoin. Il te faut un chargeur adapté qui supporte l'équilibrage. Par contre tu n'as besoin d'aucune électronique dans le robot sauf la protection contre les sur-courant (par exemple fusible) et une protection contre les décharges profondes.


Dans tout les cas, l'important, c'est du prévoir un bon chargeur, et un qui soit adapté à tes batteries.
Pour l'option 1, ça dépend du BMS : certains intègrent un convertisseur et accèptent une tension mal régulée. D'autres ne font que la protection/équilibrage, et nécessitent un vrai chargeur. Certains ne font pas l'équilibrage : à éviter (ou alors il faut recharger avec l'option 2).

Pour l'option 2, tu as besoin d'un chargeur qui permet de choisir la technologie de batteries (ou spécifique à ta techno), et le courant de charge max (ou qui charge assez doucement pour que ce ne soit pas un problème s'il charge à vitesse max).


Donc pour résumer, il te faut :
au niveau des batteries, au moins protection sur-intensité/court-circuit et protection contre la décharge profonde (une surveillance de la décharge individuelle des cellules est un plus, mais pas indispensable si tu utilises un chargeur qui refait l'équilibrage à chaque charge).
Ensuite, au niveau soit des batteries (BMS) soit du chargeur, il te faut la bonne techno, fin de charge, limitation du courant, équilibrage, et génération de la tension qu'il faut pour charger.

I haven't worked for a software startup yet, but I can confirm that robotics startups are not easy (especially not for big outdoor robots that tend to be quite expensive).

There is a lot of development to do, and it's costs a lot.

My previous company was maybe 4 years old, and still only selling a pair of proof of concept robots (ie not products expected to work really reliably, just some big groups wanting to see if there was potential or not in our technology). As far as I can see from the website, there hasn't been much progress since I left a bit more than 2 years ago (most videos are still from when I was there). Note that until I left there was not a single investor, just the boss paying us with the profits from his other company. No idea how things evolved since.

Current company, with a far more expensive robot, and 8 years old : we are just starting to sell/rent a few robots. I expect that incomes will pay the bills in about 2 years. This time, we had descent founding.

So expect a few years before you start making some cash, and some more before you start making money (if you survived until then). And the less money you get, the slower the development, and the more difficult to find investors.

 

1) To start with, you will need some money. If you need to build a robot, expect a few tens of thousands euros (if you do it on your free time, far more if you have to pay wages for a few people). This money will be hard to get by (your own, donation/investment from friends, a loan from the bank, ...). There are some grants for early stage startups (usually with some coaching in addition). You might also try to find a "sponsor" (in your case, a very big farming company, or farming material company) for which loosing some 100K€ is no big deal and that hope to get the perfect custom product).
2) Develop a proof of Concept : this doesn't need to be a working product, but a proof that your idea is valid. For example, if you want to gather the grapes, and you think the main challenge is finding and cutting them, then you might put an industial robotics arm, a camera and your laptop into a wheelbarrow and show that you can harvest a single plant. The robotics base might not be required. Nor is it to have an embeded computer if your laptop does the job, ... The important thing here is to show that you found technical solutions to the main challenges. You don't need something reliable, but good enough to take a few videos, and ideally be able to show it to investors. If you manage to get a relevant Patent, it's a plus (but not required, I'm not sure my current company has any)
3) At this point, you will probably be at the end of your seed money, so you need to convince investors to invest (significant amounts). You have at least the proof of concept to show for. The risk for the investors is still high (but not as absurdly high as in step 1), so you might find some. But they will ask for many shares in return. If you get some investors, you might additionally borrow some from the banks (in your companies name this time).
4) Now you have to transform your proof of concept into a working prototype, then an industrial prototype, and finally into a commercial product. This will require lots of time (and money). At some point, you might be able to sell a few prototypes. You might also seek more investors (the more mature your project, the easier). At latest when going industrial, you will need additionnal investor (but at that point the risk is a lot smaller).

Basically, you need money to develop (the more you have, the faster you can develop), and to get money, you have to be able to show something (the more you have to show, the more money you can get and in exchange to less shares).


One last thing : if you don't have significant money at hand, you will need to convince people to invest/give/lend some for you, while you have just a brilliant idea. Make sure you are really convinced of your idea, otherwise you will probably not manage to convince others (if you have enough to get started, then it is a bit less critical, as you can develop until the point where you have something to show without depending on anyone else)

A few more advices I gathered from 2 successive robotics startups :

- try to find someone with at least some experience in your field of application (for agriculture robots, you might try to find a son of an agricultor that helped out regularly, or someone who did it regularly as sommer jobs, or even better (but probably hard to find) someone to started working in agriculture, and then switched to engineering : nb in all cases, its far better if it is the right type of agriculture). Aternatively, find an active agricultor willing to be part of the project : either you just take him on the directors board and give him some small shares, or you pay him for a small part time job (maybe 0.5 days/week durring summer, 1 day/week during winter (when agricultors tend to have more time), and nothing for the few critical weeks in the year (harvest ,...))

- make sure to have someone on your team that knows how to speak and negociate with clients and investors (it can be the same person that is doing the tech, but often it is someone different). You can have a nice idea, if you have no investors/clients, your won't go far before running out of monney. And very soon, one person won't have time to do all the jobs of both CTO and CEO at the same time.

- find a way to be able to test frequently and cheaply. There is nothing slowing down more development that beeing unable to test. In my previous startup, I spend in average about a day per week testing the robot in the yard (big yard, rather small robot). In my current company (making submarine robots), we have a small "swimming pool" for basic testing, but still rent a ship every month or 2 for more complete tests (even if renting a ship is really expensive). For you, this means at least finding a farmer willing to let you test in one of each fields (knowing that at the begining you might do some damage, so maybe best negotiate something like you pay for the production up-front, and then you get back the value of whatever survived you failed tests). In you can, the optimal solution might be to rent your office/workshop place directly on a farm with your test field just next to it : rent will probably be low, and you can test whenever you want, and get plenty of opportunities to "feel" the needs and to communicate with the agricultor (it might even be interesting you from time to time you help him in his "painful" tasks for a day or 2 : it will give all of your employees a first hand experience of the problem)

- stay away from custom projects as much as possible : your first goal is to quickly have a MVP, and then a first commercial product. Many companies might contact you to do some custom adaptation for them : it can be a small source of revenue (even if from what I have seen, the effort and cost is nearly always under estimated, so often they cost more than mayed for!) but it also slow down your main development (so higher risk to reach the nd of your cash, or that a competetor enters the market first). So excepted maybe if the company is paying you enough to hire someone to do all the custom work, probably best deny the proposition. NB : you can do the opposit approach, and be a company specialized in building custom robots, but in this case, you have no main project from which you are taking ressources, and usually you ask far more money than if someone conviced you that they just want a "small" modification of your robot (that ends up at 1 year worth of efforts).

-try to avoid hiring only interns and people just out of university : they migh be cheaper on paper, but if you don't have at least one person with a bit of experience in each field to give them guidance, the results might be quite poor, and the development time quite long

@Oracid : as far as I remember, the fastest way to reach the setpoint (and stay there, not just cross it before overshooting) is to have some oscillations (so some overshoot). Reaching the setpoit without overshoot takes a bit longuer. But sometimes oscillations are not desired, so it's better to take a bit more time to settle but avoid overshoot/oscillations.

Quand une carte est donnée pour une intensité max et que l'intensité de blocage des moteurs est supérieure ça se comporte comment ? On ne risque pas de flinguer la carte ? 

Si le driver n'a aucune protection, il surchauffe puis crame.

Si le driver a une protection thermique, il surchauffe, puis se coupe jusqu'à avoir refroidit (nb : il risque de ne pas aprécier qu'on lui fasse le coup trop souvent)p.

Si le driver a une vrai protection contre les sur-intensités, il vas soit couper (et souvent retenter plusiuers fois par seconde), soit "hacher" le signal pour réduire le courant moyen à la valeur limite. Le risque de dommage est alors très faible.

Si le driver est prévu pour fonctionner en mode limitation de courant, alors un moteur blouué qui voudrait consommer plus de courant ne pose aucun problème : le courant est automatiquement limité à la valeur max du driver (ou celle plus faible réglée s'il autorise un réglage)
 

Je me dis que je devrais pouvoir alimenter mes capteurs via un régulateur externe de 3.3V branché sur la même batterie qui alimente mes moteurs ?

Oui, aucun problème, à 2 conditions :

1) que le GND de sortie du régulateur 3.3V soit relié à celui du pico (si le régulateur 3.3V est isolé)

2) selon la précision souhaitée, il peut être nécessaire d'éviter que le courant limentant les moteurs (en particulier coté moins) passe dans les fils reliant le - du pico au - du régulateur. Si c'est pas faisable, alors prends des gros fils pour la partie du circuit en commun le trajet batterie-moins_des_moteurs et le trajet GND_pico - GND convertisseur : plus le cable est gros, moins tu aura de perturbations dues aux moteurs
 

Pour ta carte, si tu arrives à me trouver le schéma électrique de la carte, alors je pourrais te répondre en détail. À défaut, il me faudrait au moins le texte exact écrit sur les 2 gros circuits intégrés identiques qui sont proches des connecteurs des moteurs (à priori ça devrait être les ponts en H, mais j'arrive pas à lire le texte depuis les photos que j'ai trouvées) : ça me permettrait de vérifier si les contrôleurs ont une limitation en courant ou pas.

En tout cas, la documentation autorise 4 moteurs à 1.5A max, mais sans préciser s'il y a une limitation interne ou pas, ni si on a le droit de dépasser si on utilise une seule sortie par circuit intégré, ni si les circuits intégrés sont protégés contre la surchauffe. Ces infos là se trouvent dans la doc des ponts en H à priori.

Pour la régulation de tension, si tu as le schéma électrique de ta carte, je pourrais te répondre. Sinon, tu peux regarder si tu trouve la référence du régulateur de tension : ça peut être un des 4 composants à 3 pattes, ou celui à 5 pattes. Le mieux serait de tester la continuité (au multimètre) avec le 3.3V et avec la tension d'alim : normalement, le régulateur devrait avoir 1 pin connecté à l'alim de la carte, 1 pin connecté au 3.3V, et 1 pin connecté au GND (et possiblement 2 autres pins pour d'autres fonctionnalités (on/off, feedback, ...).

En tout cas, la doc dis que tu as droit à 100mA en 3.3V pour les pins d'extension (ie hors pico lui même) : je penses qu'avec tes 7 capteurs, tu dépasse probablement. Si tu dépasse le courant max autorisé, alors une chute de tension est le mieux que tu puisse espérer (les alternatives étant un fonctionnement par intermittence, un arrêt jusqu'à ce que tu coupe l'alim, ou même de griller le régulateur)

Tu peux alimenter les moteurs par un pont en H séparé, pas de problème. Mais par pitié, n'utilise pas un L298N (j'imagine que c'est à ça que tu pensais en écrivant LN298) à moins d'alimenter les moteurs au moins en 24V : à 2A, le L298N te fait perdre environ 4V (jusqu'à 4.9V). Pour des moteurs en 12V ou moins, c'est le pire pont en H que je connaisse.

Pour alimenter la carte, 5V est possible (autorisé : 3 à 10.8V), mais la datasheet recommande au moins 6V : je ne sais pas l'impact si c'est moins.

Je ne penses pas qu'il y ait une règle fixe :

- un moteur cc commandé en PWM fixe vas forcer beaucoup si le moteur est bloqué (c'est à peu près équivalent à un moteur bloqué alimenté avec une tension U_bat*PWM/255 (si le PWM vas jusqu'à 255))

- un servo-moteur commandé en vitesse (ou un moteur cc avec encodeur commandé en vitesse par un PID) : si le moteur est bloqué, le PWM vas monter jusqu'au max : on a donc un moteur alimenté avec une tension U_bat*255/255=U_bat : le moteur vas donc chauffer énormément (beaucoup de moteurs ne supportent pas le bloquage permanent à vitesse max)

- si le controleur moteur (que ce soit celui intégré au servo ou le pont en H) dispose d'une limitation en courant, alors si le moteur est bloqué, le courant ne dépassera jamais la valeur limite (le PWM s'ajustera automatiquement à la baisse en cas de bloquage (ou d'autres mécanismes similaires)

Donc en gros, en terme de sécurité en cas de blocage, choisir par ordre de préférence :

1) Un servomoteur à rotation continue avec limitation de courant ou un moteur cc avec un pont en H avec limitation de courant max (adaptée au moteur)

2) Un moteur cc commandé en PWM fixe (pas d'asservissement de vitesse, ou asservissement qui limité le PWM si la vitesse est anormalement basse pour un PWM donné)

3) Un servomoteur à rotation continue sans limitation de courant, ou un moteur cc commandé en vitesse sans limitation de courant/détection de blocage

À savoir que si tu limites le courant, tu limites le couple, donc pour du Sumo, tu as moins de force en static.

Donc pour une application classique, je te conseillerais soit un servo avec limitation de courant, soit un moteur cc avec un pont en H qui sache limiter le courant (c'est pas standard, mais pas rare non plus, par contre je ne sais pas à quel point c'est fréquent sur les modules de pont en H pour hobbyistes).

Pour tes sumos, je penses que le plus simple est de trouver un servo assez puissant pour que quand ton robot est bloqué, les roues patinent : comme ça, pas de blocage total, et donc probablement pas de surchauffe si le moteur n'est pas trop mal conçu. Ou alors trouver un moteur explicitement prévu pour pouvoir travailler en position bloquée (ou un moteur surdimensionné pour lequel tu ne dépassera jamais un PWM de X/255

@Oracid : pour ton dernier lien de driver, c'est basé sur des mosfets discrets (les IRF3205) : ils ont une résistance de seulement 8 milliohms : à 2A traversant 2 mosfets, on est à seulement 2*2*0.008= 0.032V de perdus dans le pont en H.

Avec le peu d'info disponibles, ça m'a l'air un bon choix

Bonsoir,

Pour les moteurs avec réducteur, tu as 2 parties :

- le moteur : plus tu veux un moteur puissant (la puissance, c'est couple*vitesse), plus il sera lourd, gros, cher et gourmand en énergie.

- le réducteur : il permet de répartir la puissance entre la vitesse et le couple. À moteur donné, tu aura (approximativement) la même puissance. Mais tu peux augmenter le couple au détriment de la vitesse ou vice-versa.

Pour controler les moteurs, je te déconseille vivement les relais, qui ne permettent qu'un contrôle en tout ou rien (et ne te permettant donc pas de contrôler ta vitesse ou de tourner avec un rayon donné). Je te conseille vivement de prévoir un driver pour moteurs DC (un par moteur ou un seul qui en gère plusieurs). Je te conseilles soit d'en choisir un avec limitation de courant (ou de surchauffe), soit d'en prendre un qui supporte le courant bloqué de  tes moteurs avec une bonne marge. Autrement, si avec ton robot tu buttes contre un mur, tu risque de cramer ton driver.
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!)

Bonsoir,

j'ai peut-être (ou pas) une explication pourquoi ton robot parvient à aller en ligne droite avec des servos aillant un couple différent :

si ta consigne de vitesse est atteignable (ie acceleration pas trop importante, et couple nécessaire inférieure au couple max des servos), alors le couple max de tes servos ne joue pas de rôle, et ça ne pose donc aucun problème que tes moteurs soient un peu (beaucoup) différents. Tu pourrais même utiliser des modèles différents si tu le voulait. Cette situation est ce qu'il faut viser si tu veux un comportement reproductible, sinon le moindre changement (dans tes frottements, moteur légèrement différent (2 moteurs strictement identiques, ça n'existe pas), ...) te fera dévier de ta trajectoire.

Si en revanche tu pousses les moteurs à leur couple max (soit car tu forces trop, soit car tu accélère fortement), alors tu perds toute reproductibilité (et toute similitude entre pattes). En revanche, tu tire le max de couple de tes moteurs. Mais vu la difficulter de controler le robot dans cette situation, je ne recommande pas.

Par contre, ça n'explique pas encore pourquoi ton robot tourne maintenant en rond. Est-ce que visuellement tous les moteurs font bien leur mouvements? Est-ce que la trajectoire de toutes les pattes semble cohérente?

Tu peux aussi essayer de soulever le robot, et de vérifier si en l'air la trajectoire de toutes les pattes est bien la même (ça élimine l'effet de la poussée sur le sol).

Sinon, tu peux aussi essayer de placer tous les moteurs gauches à droite (à la même articulation) et vice versa : si le robot tourne maintenant dans le sens opposé, alors c'est un problème de moteur. Sinon le problème est soit électronique, soit soft, soit mécanique (mais les moteurs sont innocents)