Mavros: Toca una melodía a través de MAVCMD

MAV_CMD no tiene ese comando.

Si desea enviar PLAY_TUNE , debe escribir un complemento.

Pregunta para principiantes: ahora que existe el complemento ( vea esta solicitud de extracción , gracias @mortenfyhn), ¿cuál sería la forma más sencilla de tocar una melodía simple a través de mavros?

Estoy en ROS noetic, Ubuntu 20.04, ArduSub 4.0.2 en Pixhawk1. El zumbador está conectado y reproduce algo cuando se inicia el pixhawk. Pero no puedo hacer que reproduzca nada después de eso.

Yo he tratado
roslaunch mavros apm.launch fcu_url:=udp://:[email protected]:14549
y cuando lo hago
rostopic echo /mavros/state
muestra mensajes regulares, por lo que estoy bastante seguro de que la conexión funcionó.
Sin embargo, cuando intento
rostopic pub -1 /mavros/play_tune mavros_msgs/PlayTuneV2 "format: 2 tune: '>e16e8e16r16c16e8g4<g4'"
no pasa nada.

Siento que me estoy perdiendo un paso básico crucial. Se agradecería cualquier puntero en la dirección correcta. Todavía estoy aprendiendo.

No se preocupe, lo que se está perdiendo podría ser habilitar el complemento play_tune. Cuando inicias mavros, ¿obtienes una larga lista de complementos que dicen complemento cargado / en lista negra / similar? Le dice qué complementos están habilitados. Puede agregar el complemento play_tune al archivo de configuración apm_pluginlists.yaml que es leído por apm.launch . Ojalá eso lo resuelva.

¡Gracias por tu respuesta rápida!

Sí, lo entiendo
[ INFO] [1620733606.153262125]: Plugin play_tune loaded
[ INFO] [1620733606.155413105]: Plugin play_tune initialized

apm_pluginlists.yaml ve así:

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_*'

Eso es extraño. ¿Tiene QGroundControl o algo similar en ejecución? Puede utilizar su "inspector mavlink" para comprobar si está viendo el mensaje mavlink PLAY_TUNE_V2. Más allá de eso, creo que los otros mantenedores podrían ser más adecuados para resolver esto.

Oh, interesante, no aparece en QGC.

Parece que primero tendré que averiguar qué va mal aquí. Tal vez sea un problema con ArduSub.

Ah, y muchas gracias por tu tiempo :-)

Podría ser para que no aparezca en QGC incluso cuando funciona, cuando lo pienso. Es posible que el mensaje vaya directamente al pixhawk y que el pixhawk no lo pase a QGC.

@mortenfyhn PLAY_TUNE va directo al enlace FCU, por lo que es poco probable que lo vea en GCS, excepto si el firmware lo enruta de regreso.
Desafortunadamente, no es fácil capturar ese mensaje en mavros v1, solo si coloca algo entre FCU y MAVROS para capturar paquetes.

Hmm, podrías intentar construir el complemento Wireshark para inspeccionar datos (pero realmente no sé si todavía funciona o no).
Y dado que estamos tratando con firmware de código abierto, podríamos ir y ver si ArduSub acepta ese mensaje o no :)

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

Y:

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

Y:

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

Entonces: FW quiere PLAY_TUNE, el complemento envía PLAY_TUNE_V2.
Creo que debemos agregar la selección de mensajes según el tipo de AP.

Es interesante saberlo, ¡gracias por investigar!

¿Existe alguna forma (para principiantes) de evitar este problema?
¿Puedo ayudar con algo y cuál sería el lugar más eficaz para realizar el cambio?

Probablemente pueda extender el complemento para admitir mensajes PLAY_TUNE simples. @vooon , ¿cuál es la política para los cambios de API? Estoy tentado a crear un nuevo suscriptor, por lo que el complemento dice ~play_tune para mavros_msgs / PlayTune -> mavlink PLAY_TUNE, y ~play_tune_v2 para mavros_msgs / PlayTuneV2 -> mavlink PLAY_TUNE_V2. Pero eso romperá la antigua API, que usa ~play_tune para los mensajes v2.

Alternativamente, puedo agregar un parámetro que determine si espera mensajes v1 o v2 en ~play_tune , y generaré el mensaje mavlink correspondiente.

@mortenfyhn desde que estamos en la etapa 1.0, preferiría mantener la API existente.
Además, el usuario no debería preocuparse por la versión bruta del mensaje que se envía, por lo que preferiría agregar la detección de param plus.

Algo como eso:

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 desde que estamos en la etapa 1.0, preferiría mantener la API existente.

: +1:

Haré aproximadamente lo que sugieres:

• Agrega un parámetro.
• Si no está configurado, mantenga el comportamiento existente.
• Si está configurado para especificar v1 / v2, utilícelo.
• Si no está configurado y m_uas->is_ardupilotmega() == true , utilice v1.

Sí, también creo que está bien usar 0 == auto (v1 para APM / v2 para otros).

Ah, también, deberíamos simplemente convertir PlayTuneV2.msg a PLAY_TUNE.
Necesito verificar ese formato == MML (implementación de APM), luego hacer algo como eso (pseudocódigo):
''
PLAY_TUNE pt {};

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