Mavros: Téléopération par joystick

Je pense qu'il vaut mieux pas un plugin, mais un nœud de script qui utilise le plugin rc_io.

Cela inclura-t-il des éléments de point de consigne ?

Je ne suis pas très habitué aux scripts comme vous l'avez vu, je préférerais vraiment un plugin. Mais je peux vous l'envoyer en tant que plugin, puis vous pouvez le convertir en script si vous le souhaitez.

Juste je ne veux pas de code en double qui existe déjà (et fonctionne).

Je pense que ce nœud devrait s'abonner au sujet du joystick et produire des messages de substitution rc (ou point de consigne).
Envoyez-moi s'il vous plaît quelles données je dois envoyer à rc/setpoint et j'écris le script (carte des canaux, etc.).

Ok je ferais ça tout de suite

@vooon vous a envoyé l'e-mail maintenant ;)

D'accord, je verrai ça demain.

Bien sûr :+1: Merci !

Je pourrais ajouter un nœud similaire que j'ai pour cela si nécessaire. @TSC21

@tonybaltovski s'il vous plaît envoyez-le moi. Je pense que c'est un exemple utile, mais peut-être que ça doit être dans les extras.

@tonybaltovski J'ai déjà commencé un plugin, que j'ai envoyé à @vooon pour qu'il s'adapte comme il veut. Il était presque prêt pour le contrôle du point de consigne, mais la partie de priorité RC je l'ai laissée à @vooon.

Quel est le statut à ce sujet ? J'aimerais vraiment mettre la main sur cela afin de tester les consignes également :)

Peut être demain...

@TSC21 C'est juste une preuve de concept, mais cela devrait fonctionner.

je vais essayer, merci ! :) Mais ma priorité est de tester les consignes à l'aide du joystick. Si vous pouvez ajouter la possibilité de contrôler la position et la vitesse, je vous en serais reconnaissant.

Pour la vélocité, envoyez cmd_vel tant que TwistStamped pour être abonné par setpoint_velocity ;

Le contrôle de position est simple : au lieu de cmd_vel il envoie position sous forme de PoseStamped mais cela doit être un cas particulier - il doit faire la somme de la valeur de position précédente envoyée afin qu'il peut incrémenter ou décrémenter la position (ainsi les valeurs de x , y , z ne sont pas limitées à -1..1 ; ce qui est limité est la valeur qui est ajoutée à dernière valeur ; donc si le joystick envoie toujours +1 , à chaque itération, il fait +1 -> le seul doute que j'ai ici est de savoir si nous devons limiter le taux dans ce cas, donc le les itérations ne font pas monter certaines valeurs trop rapidement).
Celui-ci est abonné par setpoint_position .

Mise à jour : concernant le sujet /joy : je n'arrive pas à récupérer les données de mon joystick en utilisant le script mavteleop . Mais en utilisant le lancement universal_teleop je peux. Il doit donc manquer quelque chose dans le script.

Vous exécutez le joy_node ?

rosrun joy joy_node

27-08-2014 18:17 GMT+04:00 TSC21 [email protected] :

Mise à jour : concernant le sujet /joy : je ne parviens pas à récupérer les données de
mon joystick en utilisant le script mavteleop. Mais en utilisant universal_teleop
lancer je peux. Il doit donc manquer quelque chose dans le script.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/vooon/mavros/issues/133#issuecomment -53578566.

Non! Ouais ça marche maintenant. J'ai oublié le joy_node . Cela ne peut-il pas être inclus dans le script à lancer ?

Ok maintenant concernant le remplacement lui-même : l'écho de /mavros/rc/override n'obtenait aucune donnée car vous avez oublié le préfixe / ici :

override_pub = rospy.Publisher(args.mavros_ns + "/rc/override", OverrideRCIn, queue_size=10)

Besoin de corriger cela ou je fais un PR.
Mais il n'y a toujours pas de priorité RC sur le FCU, car les moteurs ne changent même pas la vitesse. Continuera à vérifier ce qui se passe.

@vooon RC override cela ne fonctionne pas. Le script est publié sur /rc/override , qui est abonné par rc_io.cpp . Faire écho à /mavros/rc/override me fait changer les valeurs des canaux mais rien ne se passe du côté FCU (aucun changement de rotation du moteur).

Ma priorité n'est pas l'override RC, même si j'aimerais le mettre en place. Mais je n'arrive pas à trouver quel est le problème. En attendant, pouvez-vous obtenir la vitesse de consigne et le contrôle de position s'il vous plaît ? (basé sur le commentaire ci-dessus que j'ai fait concernant les spécifications de ce type de contrôle)
Merci!

J'ai le même problème avec la commande RC. Le FCU ne l'utilise pas.

@tonybaltovski pouvez-vous essayer de déboguer la raison ? Je suis occupé avec d'autres trucs concernant POSCTL.

Lorsque je teste les remplacements avec APM, j'ai trouvé qu'il disparaît silencieusement si le message de remplacement provient de system_id != SYSID_MYGCS (par défaut : 255).

Je le change donc en 1 (valeurs par défaut de mavros) et cela fonctionne. Ou nous pourrions changer mavros system_id.

Alors qu'est-ce qui ne va pas ? system_id ou comp_id ? De quoi a-t-il besoin dans le cas du PX4 ?

Peut-être que PX4 ne gère pas les messages de remplacement RC, je ne trouve pas de gestionnaire pour le message MAVLINK_MSG_ID_RC_CHANNELS_OVERRIDE .

Peut-être que PX4 ne gère pas les messages de remplacement RC, je ne trouve pas de gestionnaire pour le message MAVLINK_MSG_ID_RC_CHANNELS_OVERRIDE .

Oui il semble que non. Eh bien tant pis, je pense que nous pouvons demander la mise en œuvre, mais je préférerais que les points de consigne fonctionnent. Pouvez-vous donner un coup de main @vooon s'il vous plaît?
Merci d'avance!

@vooon Je vais réessayer sur mon APM demain et je vous tiens au courant.

Je vais essayer de le faire demain.

Merci beaucoup @vooon !

@TSC21 J'ai presque fini, mais le contrôle de position est très sale. Besoin de le refaire pour une intégration à temps constant.

Merci @vooon ! :D quand vous avez tout fait s'il vous plaît prévenez-moi! Je serai ravi de tester ça !

Vous pouvez déjà tester tous les modes sauf -pos (et peut-être -vel ).

@vooon fait un test maintenant. Ma carte des axes est différente, c'est facile à changer, mais je vois que certains canaux sont inversés. Vous devriez également ajouter un paramètre au canal inverse, sans avoir à passer en mode de contrôle et à faire quelque chose comme z=-yaw .

Remarque : dans mon cas, ma carte des axes est :

axes_map = {
    'roll': 3,
    'pitch': 2,
    'yaw': 0,
    'throttle': 1
}

et en mode contrôle vel :

twist.twist.linear = Vector3(x=-roll, y=pitch, z=throttle)
twist.twist.angular = Vector3(z=-yaw)

Utilisez le paramètre ~axes_scale/<name> pour inverser (définissez-le sur -1.0).

Oh ok, je n'ai pas vérifié ça. Merci!

Pouvez-vous intégrer rosrun joy joy_node au lancement du script au lieu de l'ajouter au fichier launch ?

@vooon autre chose qui doit fonctionner: le nœud doit toujours envoyer les données, même s'il s'agit de 0.0, c'est-à-dire par exemple, cmd_vel doit toujours être publié même si nous ne déplaçons pas les commutateurs sur le joystick, car le mode OFFBOARD a un délai d'attente de 0,5 s et reçoit constamment des données pour rester dans ce mode ou il revient au mode précédent !

Ce que je vois, c'est que lorsque nous définissons un canal sur une valeur, cmd_vel n'envoie cette valeur qu'une seule fois. L'implémentation PX4 doit recevoir constamment des données, donc je pense que ce qui peut être fait est que cmd_vel envoie toujours la valeur de canal précédente, sauf lorsqu'il reçoit une nouvelle valeur. Cette nouvelle valeur est stockée et envoyée en permanence jusqu'à ce qu'une nouvelle valeur du canal soit définie (en utilisant les sticks analogiques bien sûr).

Ajoutez ceci à votre fichier de lancement pour le nœud joy <param name="~autorepeat_rate" value="5" />

Merci @tonybaltovski qui a fonctionné ! Mais je ne peux toujours pas modifier les paramètres à l'aide du fichier de lancement. Voici à quoi ressemble mon fichier de lancement :

<launch>
    <!-- vim: ft=roslaunch -->
    <!-- example launch script for PX4 teleop -->

    <arg name="fcu_url" default="serial:///dev/ttyACM0:57600" />
    <arg name="gcs_url" default="" />
    <arg name="tgt_system" default="1" />
    <arg name="tgt_component" default="50" />

    <node pkg="mavros" type="mavros_node" name="mavros" required="true" clear_params="true" output="screen">
        <param name="fcu_url" value="$(arg fcu_url)" />
        <param name="gcs_url" value="$(arg gcs_url)" />
        <param name="target_system_id" value="$(arg tgt_system)" />
        <param name="target_component_id" value="$(arg tgt_component)" />

        <!-- px4 blacklist -->
        <rosparam command="load" file="$(find mavros)/launch/px4_blacklist.yaml" />

        <!-- enable heartbeat send and reduce timeout -->
        <param name="conn_heartbeat" value="5.0" />
        <param name="conn_timeout" value="10.0" />
        <!-- enable mavlink autostart on USB port -->
        <param name="startup_px4_usb_quirk" value="true" />

        <!-- joystick axis parameters -->

        <!-- joystick axis map -->
        <param name="~axes_map/roll" value="3" />
        <param name="~axes_map/pitch" value="2" />
        <param name="~axes_map/yaw" value="0" />
        <param name="~axes_map/throttle" value="1" />

        <!-- joystick axis scale -->
        <param name="~axes_scale/roll" value="-1.0" />
        <param name="~axes_scale/pitch" value="" />
        <param name="~axes_scale/yaw" value="-1.0" />
        <param name="~axes_scale/throttle" value="" />

    </node>

    <node pkg="joy" type="joy_node" name="joy" required="true">
        <param name="~/autorepeat_rate" value="50" />
    </node> 
</launch>

Peut-être parce que c'est un script mavros_extras ? Mais en émettant rosparam list / j'obtiens :

/joy/autorepeat_rate
/mavros/axes_map/pitch
/mavros/axes_map/roll
/mavros/axes_map/throttle
/mavros/axes_map/yaw
/mavros/axes_scale/pitch
/mavros/axes_scale/roll
/mavros/axes_scale/throttle
/mavros/axes_scale/yaw

Je ne comprends donc pas pourquoi cela ne change pas le paramètre.

Au fait @vooon , ça devrait être axis et non axes ;) Je vais faire cette correction et faire un PR si tu veux.

Mise à jour : dieu, mon ignorance. axes est pluriel d'axe (donc c'est ok tel quel)

Mise à jour : si je fais rosparam get /mavros/axes_map/pitch j'obtiens 2 comme supposé, donc je pense que cela peut être quelque chose sur mavteleop .

Si je fais à la place :

load_map(axes_map, '/mavros/axes_map/')
load_map(axes_scale, '/mavros/axes_scale/')
load_map(button_map, '/mavros/button_map/')

sur rosrun mavteleop :

[ERROR] [WallTime: 1409327711.720875] bad callback: <function joy_cb at 0xa5ce9cc>
Traceback (most recent call last):
  File "/opt/ros/hydro/lib/python2.7/dist-packages/rospy/topics.py", line 682, in _invoke_callback
    cb(msg)
  File "/home/vision/vision_ros_ws/src/mavros/mavros_extras/scripts/mavteleop", line 187, in joy_cb
    pitch = get_axis(joy, 'pitch')
  File "/home/vision/vision_ros_ws/src/mavros/mavros_extras/scripts/mavteleop", line 92, in get_axis
    return j.axes[axes_map[n]] * axes_scale[n]
TypeError: can't multiply sequence by non-int of type 'float'

Bon le problème est résolu ! Voici ce que j'ai fait :
Sur le fichier de lancement j'avais :

<!-- joystick axis scale -->
        <param name="~axes_scale/roll" value="-1.0" />
        <param name="~axes_scale/pitch" value="" />
        <param name="~axes_scale/yaw" value="-1.0" />
        <param name="~axes_scale/throttle" value="" />

qui donnait l'erreur précédente de multiplication de séquence. changé en:

<!-- joystick axis scale -->
        <param name="~axes_scale/roll" value="-1.0" />
        <param name="~axes_scale/pitch" value="1.0" />
        <param name="~axes_scale/yaw" value="-1.0" />
        <param name="~axes_scale/throttle" value="1.0" />

L'abonnement a été résolu en changeant mavteleop avec ceci :

load_map(axes_map, '/mavros/axes_map/')
load_map(axes_scale, '/mavros/axes_scale/')
load_map(button_map, '/mavros/button_map/')

Fera un PR bientôt.

PR fait en #143.

J'ai été confondu la forme plurielle des axes.

Vous appliquez des paramètres au mauvais nœud. J'ai clairement fait un script de démarrage.

https://github.com/vooon/mavros/commit/289fa6c18113f6c0c1e1764cf4e5c37fd5abf9e2

(Commencé avant votre RP).

Vous appliquez des paramètres au mauvais nœud. J'ai clairement fait un script de démarrage.

Oui maintenant je comprends ! Merci! Annulera PR alors.

Usage:

1. démarrer la connexion FCU : roslaunch mavros px4.launch
2. démarrer la téléopération : roslaunch mavros_extras teleop.launch

Ou créez votre propre lancement avec <include file="..."> pour les deux fichiers.

Usage:
démarrer la connexion FCU : roslaunch mavros px4.launch
démarrer la téléopération : roslaunch mavros_extras teleop.launch

Merci! J'essaierai alors !

Fonctionne bien maintenant :) il suffit de changer le yaml et c'est fait (vérifier 289fa6c - devrait être roll bot poll ). Maintenant, je vais tester cela sur GCS HIL pour voir comment ça se passe. Que faut-il faire sur la partie position @vooon ?

Je me prépare aux vols du week-end, donc c'est en todo..

Je me prépare aux vols du week-end, donc c'est en todo..

Si vous indiquez myabe, je peux essayer

Je vais corriger la faute de frappe.
Vous devez également ajouter des limites de chargement RC à partir des paramètres FCU.

Au fait, je viens de remarquer que le PX4Firmware a 500 forks !

Au fait, je viens de remarquer que le PX4Firmware a 500 forks !

:D Ne surprend pas étant donné l'énorme communauté utilisant les projets dérivés Pixhawk et PX4.

Je voulais juste commenter cela. J'étais sur le point d'écrire quelque chose comme juste au moment où j'ai vu ce problème. C'est comme si la communauté lisait dans mes pensées :D. Testé, fonctionne comme un charme.

@pmukherj Pouvez-vous s'il vous plaît décrire brièvement comment vous avez réussi à faire fonctionner cela sur un système propre. Je vais développer, tester et adapter pour l'intégrer au wiki.
Merci.

@mhkabir Je pense que le meilleur endroit dans le wiki - les pages de tutoriel (actuellement n'existent pas dans l'espace mavros).

@vooon Je voulais dire wiki PX4 :) Je peux ajouter une note à README.

Chose sûre! Je veux m'assurer que je n'ai pas pris de mesures redondantes (la mise à niveau du firmware vers la version dev n'a peut-être pas été nécessaire, etc.). Je vais écrire quelque chose aujourd'hui.

@mhkabir Je n'ai pas pu voler aujourd'hui en raison du mauvais temps au Canada, mais lors des tests au banc, j'ai remarqué que lorsqu'une commande r,p,y non nulle est envoyée (à l'aide du joystick), il n'y a aucun changement audible dans la puissance du moteur. Lorsque je contrôle la poussée (via le joystick f710), je peux entendre les moteurs gémir de haut en bas. Lorsque je balance le corps du quadrirotor, je peux entendre les moteurs gémir et essayer de compenser. Cependant, lorsque je lui donne une grande commande ar,p,y pour cibler via la commande de point de consigne/attitude, une telle compensation n'est pas entendue. Y a-t-il des messages de retour implémentés dans le cadre de mavros, quelque chose qui reconnaît une commande en cours d'exécution (peut-être les puissances motrices individuelles ou quelque chose ?).
Je veux m'assurer que cela fonctionne avant de le documenter, et je préfère le prouver sur un banc que par un crash :P.

@pmukherj Pouvez-vous m'envoyer un IM sur Gitter ou Hangouts ([email protected]). Passons en revue avec cela. J'ai besoin de plus d'informations sur votre configuration.
Il y a un message LOCAL_POSITION_TARGET_NED et un message ATTITUDE_TARGET qui ne sont pas dans mavros. Je vais le corriger dans le cadre de la refactorisation du code que nous voulons faire pour les plugins de point de consigne. De plus, pour ces flux cibles de contrôleur, vous devez les diffuser explicitement du côté PX4.
Le contrôle hors-bord est expérimental et ce plugin n'a pas été testé, donc je ne sais pas encore où les choses vont mal. J'ai besoin de plus de données.

Désolé, c'est vrai, j'étais occupé à faire des vols DAQ.
Donc, ATTITUDE_TARGET ressemble exactement à ce dont j'ai besoin pour m'assurer que le pixhawk essaie d'atteindre les commandes du joystick que je lui envoie. J'ai un pixhawk 3DR avec un ordinateur plus grand monté à bord (la pile px4 fonctionne fabuleusement d'ailleurs, il manque juste quelques modes de vol).

Je peux examiner cela ou avez-vous un fork avec cela mis en œuvre?

@pmukherj Je cherche à obtenir des cibles d'attitude et de position dans mon plugin visualiseur. Il y a quelques problèmes de tf, donc je les résous.
Quel ordinateur compagnon de bord utilisez-vous ?
Concernant les cibles, vous n'avez pas vraiment besoin de mettre en œuvre quoi que ce soit. Utilisez simplement le pont UDP que nous avons sur mavros et patchez un lien vers QGC sur votre ordinateur de développement. Vous pouvez tout voir et tout tracer là-bas.

Désolé! Déménagement des bureaux au cours des nouvelles années.
Je teste avec toutes sortes d'ordinateurs (odroïdes, TK1, etc.). Je vais essayer d'utiliser un pont UDP.
Je suppose que je peux utiliser l'une des connexions de télémétrie dans le pixhawk? En plus de l'ordinateur compagnon, j'ai également une connexion sans fil dans l'un des ports de télémétrie (comme c'est le cas avec 3DR pixhawk).

Ouais. Vérifié que les points de consigne fonctionnent réellement ! Les points de consigne internes l'acceptent et les sorties du contrôleur sont également visibles. Maintenant pour les tests en vol :). Souhaite moi bonne chance.

@pmukherj Vous pouvez connecter le compagnon à votre port TELEM2 et le démarrer via extras.txt dans votre carte microSD.
C'est bien que les consignes fonctionnent. Bonne chance pour les vols.
Veuillez vérifier : http://www.pixhawk.org/dev/ros/mavros_offboard
En bas, il y a une ligne de code vide, où vous devez ajouter la commande mavros que vous avez utilisée pour passer en mode hors-bord (en option pour les personnes s'ils le souhaitent)

Aussi, pouvez-vous s'il vous plaît ajouter la commande pour les essais en vol ici : http://www.pixhawk.org/dev/offboard_control/testing

Il suffit de mettre les points, et je vais le nettoyer.

@vooon Le plugin joystick fonctionne bien, mais plante trop gravement si l'un des axes n'est pas trouvé ou hors de portée, etc.

Nous pouvons ajouter une limitation min/max.

Notez que ce n'était pas un plugin, node.

Vrai ;)
Je pense que je vais le faire en tant que plugin, car le script/python semble plutôt déroutant + peu fiable.

Je ne veux pas de plugin car il réinvente la roue. Réécriture maximale de python vers C++.
Mais vraiment pas nécessaire lorsque mavteleop s'exécute sur desctop et contrôle les mavros d'OBC.

@vooon avez-vous pensé à un moyen de résoudre cela ?