Modification d'un robot de piscine?

En modelisme, il y des ferus de sous-marins. Il utilise des émetteurs dont les fréquences sont autour des 40 MHz :wink:
Les hautes fréquences ont du mal dans l’eau. Donc la plus basse fréquence c’est le mieux.

1 « J'aime »

Petite question à propos de ROS/ROS2: existe il une intégration avec home assistant, j’essaie d’avoir des infos pour mon projet de tondeuse et ça pourrait changer la donne comparer QGC ou mission planner

Hello,
Il n’y a pas à ma connaissance d’intégration. Mais ROS intègre officiellement MQTT via un nodelet. Il se charge de faire un bridge entre les messages (topics) ROS et MQTT, ce qui rend l’intégration assez naturelle.
http://wiki.ros.org/mqtt_client

Autrement il y a des intégrations tierces Node-red via du json.
Je n’ai pas testé…

Oui je viens de voir, interressant. J’ai un pixhawk 3 je n’ai plus de radio pour piloter à distance, du coup je vais tester avec un esp32 qui me servira de récepteur en Bluetooth avec une manette de PS3. Du coup je vais devoir installer micro ROS dessus ça pourrait aussi servir à faire les transmissions de donnée via wifi sur le pc qui exécutera ROS2. Et en même temp en mqtt pour ha. Ça peu m’aider à débloquer le projet.

1 « J'aime »

Eh behh! je vois que, depuis mon dernier échange du 17/05, la discussion évolue et mobilise un peu plus de monde !
Les « dronistes » s’excitent et ça me plait bien…
Cependant, je me dois de doucher un peu leurs ardeurs:
une tondeuse, ou un robot de piscine, n’a pas besoin de trucs aussi complexe que la gestion des 3 axes, la redondance de GPS et accéléromètres pour fonctionner et le souci des modules sur batteries c’est leur autonomie due à la puissance d’aspiration demandée par le moteur-pompe qui sert à grimper aux parois.
C’est la raison pour laquelle je viens de me payer un robot HS (Sweepy M3 de chez Zodiac).
50€ chez LBC et à 30 bornes de chez moi… j’ai mis une journée à le remettre en route en lui re-fabricant une hélice de pompe en impression 3D.
Il tourne en ce moment dans mon bassin, mais il rame un peu dès qu’il faut grimper au mur car la tempo (non-réglable…) qui gère l’inversion de sens de marche est trop courte, 45s alors qu’il faudrait au moins 1mn30, et il n’atteint jamais la ligne d’eau.
Par contre, il est équipé d’un « pied escamotable » qui lui permet de tourner de façon aléatoire.
Toute l’électronique est dans un boitier sur le chariot qui reste à l’extérieur, et le robot à 3 moteurs:

  • le moteur « turbine d’aspiration »
  • le moteur de traction AV/AR
  • le moteur du « pied » qui assure la rotation

Pour l’instant, j’en suis là. je n’ai pas encore ouvert le boitier étanche des moteurs, mais je pense y ajouter un boitier (étanche) avec un esp32 et un accéléromètre pour tester la possibilité d’enregistrer les déplacements et la mise en position verticale ainsi que la mise « en crabe » sur la ligne d’eau.
Tout ça devra pouvoir échanger avec une « base », en wifi chaque fois que le robot sort de l’eau.
C’est seulement après ces tests que je pourrais envisager un vrai programme de pilotage…

Mais avant ça… il faut d’abord que je trouve un bout de code pour gérer un ESP et un accéléro :joy::wink:
SI quelqu’un à une piste (!?)

1 « J'aime »

Oui un robot de piscine n’a pas besoin d’autant de truc pointu il est vrai mais l’utilisation des logiciel de drones ( par ce que le robot est un drone par définition), mais peu simplifier et mieux gérer leur positions/évolution dans leur environnements.
Le problème est que à l’heure actuel il n’existe que des cartes trop évolué pour ce que l’ont veux faire, cependant même avec un arduino MEGA on peu faire beaucoup, l’esp n’a été implémenté que très récemment donc encore du chemin à faire.

Pour la tondeuse c’est réellement essentiel mais c’est un autre sujet :wink:

Sinon je suis en train de tester BlueOS pour faire ça directement sur rpi, je n’en suis qu’à l’installation pour le moment mais ça pourrait faire.

Bonjour je me lance aussi, j’ai des pièces de vieux dolphin diagnostic a 2 moteurs ( turbine et traction) y a 3 fils, pour le moment, sur table j’ai connecté le moteur turbine sur l’alimentation, et le moteur traction via un relais inverseur 2 pôles qui inverse donc le + et le - . Je pensais utiliser le 3 ème fil pour piloter le relais et laisser le relais dans le robot et mettre un esp dans l’alimentation pour pililoter le relais , mais tant qu’à laisser de l’électronique dans le robot autant y mettre une petite carte esp32 avec 2 relais intégrés. Il me reste donc adapter le code de allpassion pour esphome. Si quelqu’un l’a déjà fait je suis preneur.
@stephg38
?
Nota: allpassion a aussi proposé une solution pour ceux qui ont 3 fils tout en laissant l’esp dans le bloc alim, la concession c’est qu’il coupe la turbine quand le rabot passe en marche arrière. Ça me tente moins.

bonjour
je partage donc mon code.
la turbine démarre dès que l’alim est sur ON, les marches AV et Ar sont gérées par l’ESP selon ce code (j’ai essayé de reproduire ce que fait mon dolphin diagnostic 2001)
(câblage a venir)

esphome:
  name: esp32-robot-piscine
  friendly_name: ESP32-robot-piscine
# Démarrer le script lors du démarrage de l'ESP
  on_boot:
    priority: 600
    then:
      - script.execute: demarre_sequence

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "xxxxxxxxxxxxxx"

ota:
  - platform: esphome
    password: "xxxxxxx"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esp32-Robot-Piscine"
    password: "xxxxxx"



captive_portal:
# Enable Web server.
web_server:
  port: 80

switch:
  - platform: gpio
    name: "relais1"
    id: relais1
    pin: 16
  - platform: gpio
    name: "relais2"
    id: relais2
    pin: 17

  - platform: template
    name: "marche avant"
    id: marche_av
    turn_on_action: 
      then:
        - switch.turn_on: relais1
        - switch.turn_on: relais2
    turn_off_action: 
      then:
        - switch.turn_on: relais1
        - switch.turn_off: relais2
  - platform: template
    name: "marche arriere"
    id: marche_ar
    turn_on_action: 
      then:
        - switch.turn_off: relais1
        - switch.turn_off: relais2
    turn_off_action: 
      then:
        - switch.turn_on: relais1
        - switch.turn_off: relais2


globals:
  - id: global_random_delay1
    type: int
    restore_value: no
    initial_value: '0'
  - id: global_random_delay2
    type: int
    restore_value: no
    initial_value: '0'

script:
  - id: demarre_sequence
    mode: single
    then:
      - delay : 10s # attente que le robot tombe au fond de l'eau
      - switch.turn_on: marche_av # marche AV
      - delay: 4s
      - switch.turn_off: marche_av # marche AV
      - delay: 1s
      - switch.turn_on: marche_ar #marche AR
      - delay: 4s
      - switch.turn_off: marche_ar #marche AR
      - delay: 1s
      - script.execute: sequence_nettoyage

  - id: sequence_nettoyage
    mode: restart
    then:
      - switch.turn_on: marche_av # marche AV
      - lambda: |-
          int random_delay2 = 30000 + rand() % 30000;  // Générer un délai entre 30s et 60s
          id(global_random_delay1) = (random_delay1);
      - logger.log:
          format: "Délai aléatoire: %.1f secondes"
          args: ['id(global_random_delay1) / 1000.0']
      - delay: !lambda "return id(global_random_delay1);"
      - switch.turn_off: marche_av # arrêt marche av
      - delay : 1s
      - switch.turn_on: marche_ar # marche AR
      - lambda: |-
          int random_delay2 = 30000 + rand() % 30000;  // Générer un délai entre 30s et 60s
          id(global_random_delay2) = (random_delay2);
      - logger.log:
          format: "Délai aléatoire: %.1f secondes"
          args: ['id(global_random_delay2) / 1000.0']
      - delay: !lambda "return id(global_random_delay2);"
      - switch.turn_off: marche_ar # arrêt marche AR
      - delay : 1s
      - script.execute: sequence_nettoyage

Bonjour @cocof ,
Je suis plongé depuis 2 jours dans des problèmes de tracker GPS avec HA-companion, je n’avais pas suivi tes dernières propositions, et je trouve ça tout à fait intéressant, même si la moitié de ton code me passe largement au-dessus de la tête, pour l’instant.

Je suis assez d’accord avec toi, il est préférable de ne pas laisser décoller le robot du mur (surtout si, comme moi, on imagine, à terme, de suivre sa trajectoire).

Je vais te « filer le train », une fois que j’aurais testé la programmation d’un de mes esp.