Contrôle à distance

a marqué ce sujet comme résolu.

Bonjour

J’ai besoin de vous pour orienter mes recherches.

Je voudrais piloter un bras robotisé a distance depuis une page web.

Mes contrainte : le serveur qui gère le robot n’est pas le même que celui qui affiche la page web.

Je cherche donc comme faire communiquer les deux serveurs avec les moins de latence possible et ce avec plusieurs requête par seconde.

Je suis preneur de toutes idées ;)

Merci

+0 -0

Salut \o

C’est une question super vague que tu nous poses là.

La contrainte que tu nous poses n’en ai en fait pas vraiment une. Tu as la main sur le serveur qui contrôle le bras je suppose ?

Il peut écouter soit de l’UDP, du TCP/IP ou à un plus haut niveau attendre des requêtes HTTP.
Si tu veux diminuer la latence au maximum, utilise de l’UDP mais j’ai du mal à saisir la nécessité.

En résumer ce que tu dois savoir faire :

  • Afficher une page sur le serveur web
  • Envoyer un datagramme UDP depuis le serveur web
  • Recevoir un datagramme sur le serveur de commande
  • Commander le robot

Où bloques-tu donc ?

+0 -0

Hummm…

Les Websockets, c’est entre le navigateur Web et le serveur Web.
Tu peux t’en servir entre 2 serveurs quelconque mais ça n’a aucun intérêt !

Ça ne te permettra pas de communiquer entre le serveur Web et serveur de commande.

Après, bien-sûr, il faudra aussi que tu designes la communication entre l’utilisateur et ton serveur Web. Tu as là aussi un large éventail de choix dont font parti les Websockets (en as-tu réellement besoin là encore, pas sûr).


Avant de foncer tête baisser sur les protocoles et technos à utiliser.
Pose toi la question que veux-tu faire ?

L’utilisateur va envoyer quoi comme donnée ? À quelle vitesse ? Comment (navigateur Web ? Client lourd ?)
Plus généralement quelle est l’interface utilisateur ?

C’est ça qui va déterminer le protocole à utiliser pas l’inverse !

Le plus pratique pour l’utilisateur, il ne me semble pas que ce soit les Websockets.
Sans connaître ton projet, il me semble que l’utilisateur va vouloir faire :

  • Axe1 : 180°
  • Axe2 : 25°
  • Axe3 : 30°
  • Pince : 10°
  • PinceAction : Fermer

En gros, ils listent les actions. Une API REST me semble adapté.
Le navigateur présente une page Web permettant d’utiliser cet API REST.
Il y a plusieurs avantages dont la possibilité d’utiliser plus tard un client lourd.

En utilisant les Websockets l’utilisateur sera obligé d’utiliser un navigateur Web, ce qui rend difficile le scripting d’actions.

+0 -0

L’utilisateur passera bien par une page web.

Les mouvements se font par appuies sur une touche.

  • Axe 1 : (touche A = 5° / sec) (touche Q = -5° / sec)
  • Axe 2 : (touche Z = 5° / sec) (touche S = -5° / sec)

Et je pense aussi par mouvement de la souris a terme.

+0 -0
  • Est-ce-que tes utilisateurs seront-ils principalement sur PC ou mobile ? En 3/4G les websockets peuvent être instable selon l’endroit.

  • Combien d’utilisateurs/robot en même temps ? Peu d’utilisateur -> Du XHR/ajax polling pourait suffir.

  • Ton système est accompagné d’une webcam en direct ? ou d’un indicateur/schéma ? Les websockets ne sont pas bloqué dans la queue contrairement à xhr/ajax où elles se font une par une.

Les websockets sont un peu plus complexe à mettre en place (car moins utilisé et donc moins d’outils) que l’XHR/AJAX.

Tu as sockjs compatible javascript et python.

Un seul utilisateur sur pc.

Il y a un système de streaming vidéo qui utilise les websockets et un système en cours de recherche qui utilisera opencv pour du guidage en temps réel.

Je pense m’orienter vers les websockets. Mais les ressource en français sont bien maigre et pas à la porté de mon niveau actuel…

Mon post sur ce système via les websockets : ici

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte