Mavros: Jouer un morceau via MAVCMD

MAV_CMD n'a pas une telle commande.

Si vous voulez envoyer PLAY_TUNE , alors vous devez écrire un plugin.

Question de débutant : maintenant que le plugin existe ( voir cette pull request - merci @mortenfyhn) quel serait le moyen le plus simple de jouer un morceau simple via mavros ?

Je suis sur ROS noetic, Ubuntu 20.04, ArduSub 4.0.2 sur Pixhawk1. Le buzzer est connecté et joue quelque chose lorsque le pixhawk démarre. Mais je n'arrive pas à le faire jouer après ça.

j'ai essayé
roslaunch mavros apm.launch fcu_url:=udp://:[email protected]:14549
et quand je le fais
rostopic echo /mavros/state
il affiche des messages réguliers, donc je suis assez confiant que la connexion a fonctionné.
Cependant, quand j'essaye
rostopic pub -1 /mavros/play_tune mavros_msgs/PlayTuneV2 "format: 2 tune: '>e16e8e16r16c16e8g4<g4'"
Rien ne se passe.

J'ai l'impression qu'il me manque une étape fondamentale cruciale. Tout pointeur dans la bonne direction serait apprécié. Je suis toujours en train d'apprendre.

Pas de soucis, il vous manque peut-être simplement l'activation du plugin play_tune. Lorsque vous lancez mavros, obtenez-vous une longue liste de plugins disant plugin chargé / blacklisté / similaire ? Il vous indique quels plugins sont activés. Vous pouvez ajouter le plugin play_tune au fichier de configuration apm_pluginlists.yaml qui est lu par apm.launch . Espérons que cela le résout.

Merci pour votre réponse rapide!

Ouais, je reçois
[ INFO] [1620733606.153262125]: Plugin play_tune loaded
[ INFO] [1620733606.155413105]: Plugin play_tune initialized

apm_pluginlists.yaml ressemble à ceci :

plugin_blacklist:
# common
- actuator_control
- ftp
- safety_area
- hil
# extras
- altitude
- debug_value
- image_pub
- px4flow
- vibration
- vision_speed_estimate
- wheel_odometry

plugin_whitelist: []
#- 'sys_*'

C'est étrange. Avez-vous QGroundControl ou quelque chose de similaire en cours d'exécution ? Vous pouvez utiliser son "inspecteur mavlink" pour vérifier si vous voyez le message mavlink PLAY_TUNE_V2. Au-delà de cela, je pense que les autres mainteneurs pourraient être mieux adaptés pour comprendre cela.

Oh, intéressant, ça n'apparaît pas dans QGC.

On dirait que je vais d'abord devoir comprendre ce qui ne va pas ici. C'est peut-être un problème avec ArduSub.

Oh et merci beaucoup pour votre temps :-)

C'est peut-être pour que cela n'apparaisse pas dans QGC même quand cela fonctionne, quand j'y pense. Le message peut aller directement au pixhawk, et le pixhawk peut ne pas le transmettre à QGC.

@mortenfyhn PLAY_TUNE va directement au lien FCU, il est donc peu probable de le voir sur GCS, sauf si le micrologiciel le renvoie.
Malheureusement, il n'est pas facile de capturer ce message dans mavros v1, uniquement si vous mettez quelque chose entre FCU et MAVROS pour capturer les paquets.

Hmm, vous pouvez essayer de créer un plugin Wireshark pour inspecter les données (mais je ne sais pas vraiment s'il fonctionne toujours ou non).
Et puisque nous avons affaire à un firmware open source, nous pourrions aller voir si ArduSub accepte ce message ou non :)

https://github.com/ArduPilot/ardupilot/blob/0cd97ce3d8f394e2b853b1f835abf74e6488daf5/libraries/GCS_MAVLink/GCS_Common.cpp#L3494 -L3497

Et:

https://github.com/ArduPilot/ardupilot/blob/0cd97ce3d8f394e2b853b1f835abf74e6488daf5/libraries/AP_Notify/ToneAlarm.cpp#L450 -L469

Et:

https://github.com/mavlink/mavros/blob/8b9a32ac323e79cef826ee5f39aeb07a1162d240/mavros_extras/src/plugins/play_tune.cpp#L28 -L31

Donc : FW veut PLAY_TUNE, le plugin envoie PLAY_TUNE_V2.
Je pense que nous devons ajouter une sélection de message en fonction du type d'AP.

Intéressant à savoir, merci d'avoir étudié !

Existe-t-il un moyen (convivial pour les débutants) de contourner ce problème ?
Puis-je aider avec quoi que ce soit et quel serait l'endroit le plus efficace pour effectuer le changement ?

Je peux probablement étendre le plugin pour prendre en charge les messages PLAY_TUNE simples. @vooon , quelle est la politique pour les changements d'API ? Je suis tenté de créer un nouvel abonné, donc le plugin lit ~play_tune pour mavros_msgs/PlayTune -> mavlink PLAY_TUNE, et ~play_tune_v2 pour mavros_msgs/PlayTuneV2 -> mavlink PLAY_TUNE_V2. Mais cela brisera l'ancienne API, qui utilise ~play_tune pour les messages v2.

Alternativement, je peux ajouter un paramètre qui détermine s'il attend des messages v1 ou v2 sur ~play_tune , et j'afficherai le message mavlink correspondant.

@mortenfyhn puisque nous sommes au stade 1.0, je préférerais conserver l'API existante.
De plus, l'utilisateur ne devrait pas se soucier de la version du message envoyée, je préférerais donc ajouter param plus la détection.

Quelque chose comme ca:

void connection_cb() {
  int new_ver = 0
  if (nh.getParam("message_version", new_ver) {
    // check 1 vs 2
  } 
  if (new_ver == 0) {
    new_ver = m_uas->is_ardupilotmega() ? 1 : 2;
  }

  message_version = new_ver;
}

@mortenfyhn puisque nous sommes au stade 1.0, je préférerais conserver l'API existante.

:+1:

Je vais faire à peu près comme tu me proposes :

• Ajoutez un paramètre.
• S'il n'est pas défini, conservez le comportement existant.
• Si défini pour spécifier v1/v2, utilisez-le.
• Si non défini et m_uas->is_ardupilotmega() == true , utilisez la v1.

Oui, je pense aussi qu'il est possible d'utiliser 0 == auto (v1 pour APM / v2 pour les autres).

Ah, aussi, nous devrions simplement convertir PlayTuneV2.msg en PLAY_TUNE.
Besoin de vérifier ce format == MML (implémentation d'APM), puis faites quelque chose comme ça (pseudocode):
```
PLAY_TUNE pt{} ;

mavlink::set_string(pt.tune, tune->tune);
mavlink::set_string_z(pt.tune2, tune->tune[pt.tune.size():]);
``