Mavros: Joystick teleoperation

Acho melhor não um plugin, mas um nó de script que usa o plugin rc_io.

Isso incluirá coisas de ponto de ajuste?

Não estou muito acostumado com os scripts como você viu, realmente prefiro um plugin. Mas posso enviar isso como um plugin e, em seguida, você pode convertê-lo em um script, se quiser.

Só não quero código duplicado que já existe (e funciona).

Em minha opinião, este nó deve se inscrever no tópico de joystick e produzir mensagens de substituição de rc (ou ponto de ajuste).
Envie-me por favor quais dados devo enviar para rc / setpoint e eu escrevo o script (mapa do canal, etc).

Ok, eu faria isso imediatamente

@vooon lhe enviou o e-mail agora;)

Ok, vou ver amanhã.

Claro: +1: Obrigado!

Eu poderia adicionar um nó semelhante que tenho para isso, se necessário. @ TSC21

@tonybaltovski por favor envie para mim. Acho que é um exemplo útil, mas talvez deva ser em extras.

@tonybaltovski Já comecei um plugin, que enviei para @vooon para que ele se adapte do jeito que ele quiser. Estava quase pronto para o controle do ponto de ajuste, mas a parte de sobreposição de RC deixei para @vooon.

Qual é o status disso? Eu realmente gostaria de ter uma mão sobre isso para testar também os pontos de ajuste :)

Talvez amanhã...

@ TSC21 É apenas uma prova de conceito, mas deve funcionar.

Vou tentar, obrigado! :) Mas minha prioridade é testar os pontos de ajuste usando o joystick. Se você puder adicionar a possibilidade de controle de posição e velocidade, eu ficaria muito grato.

Para velocidade, envie cmd_vel como TwistStamped para ser inscrito por setpoint_velocity ;

O controle de posição é simples: em vez de cmd_vel ele envia position como PoseStamped mas este tem que ser um caso particular - tem que somar o valor da posição anterior enviado para que pode aumentar ou diminuir a posição (então os valores de x , y , z não são limitados a -1..1; o que é limitado é o valor que é adicionado a último valor; portanto, se o joystick está sempre enviando +1 , em cada iteração ele soma +1 -> a única dúvida que tenho aqui é se temos que limitar a taxa neste caso, então iterações não aumentam os valores muito rapidamente).
Este é assinado por setpoint_position .

Atualização: em relação ao tópico /joy : Não consigo recuperar nenhum dado do meu joystick usando o script mavteleop . Mas usando o lançamento de universal_teleop , posso. Portanto, deve haver algo faltando no script.

Você executa o joy_node?

rosrun joy joy_node

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

Atualização: em relação ao tópico / joy: Não consigo recuperar nenhum dado do
meu joystick usando o script mavteleop. Mas usando o universal_teleop
lançar eu posso. Portanto, deve haver algo faltando no script.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/vooon/mavros/issues/133#issuecomment -53578566.

Não! Sim, funciona agora. Esqueceu o joy_node . Isso não pode ser incluído no script a ser lançado?

Ok, agora com relação à substituição em si: ecoando /mavros/rc/override não estava recebendo nenhum dado porque você esqueceu o prefixo / aqui:

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

Preciso corrigir isso ou faço um PR.
Mas ainda não há controle de RC na FCU, já que os motores nem mesmo mudam a velocidade. Continuaremos a verificar o que está acontecendo.

@vooon RC override não está funcionando. O script está sendo publicado em /rc/override , que está sendo inscrito por rc_io.cpp . Ecoar /mavros/rc/override me dá os valores do canal mudando, mas nada acontece no lado da FCU (sem mudanças na rotação do motor).

Minha prioridade não é substituir o RC, embora eu queira configurá-lo. Mas não consigo descobrir qual é o problema. Nesse meio tempo, você pode implementar a velocidade do ponto de ajuste e o controle de posição? (com base no comentário acima que fiz sobre as especificações desse tipo de controle)
Obrigado!

Eu tenho o mesmo problema com a substituição do RC. A FCU não o utiliza.

@tonybaltovski você pode tentar depurar o motivo? Estou ocupado com outras coisas relacionadas ao POSCTL.

Quando testo as substituições com APM, descobri que ele cai silenciosamente se a mensagem de substituição vier de system_id! = SYSID_MYGCS (padrão: 255).

Então eu mudo para 1 (padrões mavros) e funciona. Ou podemos mudar mavros system_id.

Então, o que há de errado? system_id ou comp_id ? O que é necessário no caso do PX4?

Talvez o PX4 não lide com mensagens de substituição RC, não consigo encontrar o manipulador para MAVLINK_MSG_ID_RC_CHANNELS_OVERRIDE mensagem.

Talvez o PX4 não lide com mensagens de substituição RC, não consigo encontrar o manipulador para MAVLINK_MSG_ID_RC_CHANNELS_OVERRIDE mensagem.

Sim, parece que não. Que pena, acho que podemos pedir a implementação, mas prefiro que os pontos de ajuste funcionem. Você pode ajudar @vooon, por favor?
Desde já, obrigado!

@vooon , vou tentar

Vou tentar fazer amanhã.

Muito obrigado @vooon!

@ TSC21 Estou quase terminando, mas o controle de posição está muito sujo. Precisa refazer para integração em tempo constante.

Obrigado @vooon! : D quando você terminar, por favor me avise! Terei o maior prazer em testar isso!

Você já pode testar todos os modos, exceto -pos (e talvez -vel ).

@vooon fazendo um teste agora. Meu mapa de eixos é diferente, isso é fácil de mudar, mas vejo que alguns canais estão invertidos. Você deve adicionar um parâmetro também ao canal reverso, sem ter que ir para o modo de controle e fazer algo como z=-yaw .

Nota: no meu caso, meu mapa de eixo é:

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

e no modo de controle vel:

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

Use o parâmetro ~axes_scale/<name> para reverter (defina-o como -1,0).

Oh ok, não verifiquei isso. Obrigado!

Você pode integrar rosrun joy joy_node na inicialização do script em vez de adicioná-lo ao arquivo launch ?

@vooon outra coisa que precisa estar funcionando: o nó deve estar sempre enviando os dados, mesmo que seja 0,0, ou seja, por exemplo, cmd_vel deve estar sempre publicando mesmo que não movamos os interruptores no joystick, porque o modo OFFBOARD tem um tempo limite de 0,5s e como estar constantemente recebendo dados para permanecer nesse modo ou ele reverte para o modo anterior!

O que estou vendo é que quando definimos um valor para um canal, cmd_vel apenas envia esse valor uma vez. A implementação PX4 precisa estar constantemente recebendo dados, então acho que o que pode ser feito é cmd_vel enviar sempre o valor do canal anterior, exceto quando receber um novo valor. Esse novo valor é armazenado e enviado constantemente até que um novo valor do canal seja definido (usando os interruptores analógicos para fora do curso).

Adicione isso ao seu arquivo de inicialização para o nó de alegria <param name="~autorepeat_rate" value="5" />

Obrigado @tonybaltovski que funcionou! Mas ainda não consigo alterar os parâmetros usando o arquivo de inicialização. Veja como meu arquivo de inicialização se parece:

<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>

Talvez porque este seja um script mavros_extras ? Mas emitindo rosparam list / eu recebo:

/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

Portanto, não consigo entender por que isso não muda o parâmetro.

A propósito, @vooon , deve ser axis e não axes ;) Farei essa correção e farei um PR, se quiser.

Atualização: deus, minha ignorância. eixos é plural de eixos (então está tudo bem como está)

Atualização: se eu fizer rosparam get /mavros/axes_map/pitch , recebo 2 como deveria, então acho que pode ser algo em mavteleop .

Se eu fizer isso:

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

em 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'

Ok, o problema está resolvido! Aqui está o que eu fiz:
No arquivo de inicialização, eu tinha:

<!-- 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="" />

que estava dando o erro anterior de multiplicação de seqüência. alterado para:

<!-- 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" />

A assinatura foi resolvida com a alteração de mavteleop com isto:

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

Farei um PR em breve.

RP feito em # 143.

Fiquei confuso com a forma plural dos eixos.

Você aplica parâmetros ao nó errado. Eu simplesmente fiz o script de inicialização.

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

(Iniciado antes do seu PR).

Você aplica parâmetros ao nó errado. Eu simplesmente fiz o script de inicialização.

Sim, agora eu entendo! Obrigado! Vou cancelar o PR então.

Uso:

1. iniciar conexão FCU: roslaunch mavros px4.launch
2. iniciar a teleoperação: roslaunch mavros_extras teleop.launch

Ou crie seu próprio lançamento com <include file="..."> para ambos os arquivos.

Uso:
iniciar conexão FCU: roslaunch mavros px4.launch
iniciar a teleoperação: roslaunch mavros_extras teleop.launch

Obrigado! Vou tentar então!

Funcionando bem agora :) só tinha que mudar o yaml e pronto (verifique 289fa6c - deve ser roll bot poll ). Agora vou testar isso no GCS HIL para ver como funciona. O que deve ser feito na position part @vooon?

Estou me preparando para voos de fim de semana, por isso ...

Estou me preparando para voos de fim de semana, por isso ...

Se você apontar meu marido, posso tentar

Vou corrigir erro de digitação.
Também é necessário adicionar limites de carregamento RC dos parâmetros FCU.

Aliás, acabei de notar que o PX4Firmware possui 500 garfos!

Aliás, acabei de notar que o PX4Firmware possui 500 garfos!

: D Não surpreende dada a enorme comunidade que usa projetos derivados Pixhawk e PX4.

Só queria comentar sobre isso. Eu estava prestes a escrever algo assim como vi esta edição. É como se a comunidade lesse minha mente: D. Testei, funciona como um encanto.

@pmukherj Você pode descrever breves etapas sobre como você fez isso funcionar em um sistema limpo. Vou expandir, testar e adaptar para colocar isso no wiki.
Obrigado.

@mhkabir Acho que é o melhor lugar nas páginas wiki - tutorial (atualmente não existe no espaço mavros).

@vooon , quis dizer wiki PX4 :) Posso adicionar uma nota ao README.

Coisa certa! Quero ter certeza de que não tomei nenhuma medida redundante (atualizar o firmware para a versão dev pode não ter sido necessário, etc.). Vou escrever algo hoje.

@mhkabir Eu não pude voar hoje devido ao mau tempo no Canadá, mas durante o teste de bancada percebi que quando um comando r, p, y diferente de zero é enviado (usando o joystick), não há alteração audível na potência do motor. Quando eu controlo o impulso (por meio do joystick f710), posso ouvir o zumbido dos motores para cima e para baixo. Quando giro o corpo do quadrotor, posso ouvir o zumbido dos motores e tento compensar. No entanto, quando eu dou a ele um grande comando ar, p, y para atingir o alvo por meio do comando de ponto de ajuste / atitude, essa compensação não é ouvida. Há alguma mensagem de feedback implementada como parte dos mavros, algo que reconhece um comando sendo implementado (talvez os poderes motores individuais ou algo assim?).
Quero ter certeza de que isso está funcionando antes de documentar, e prefiro prová-lo em uma bancada do que por meio de um acidente: P.

@pmukherj Você pode me
Há uma mensagem LOCAL_POSITION_TARGET_NED e uma mensagem ATTITUDE_TARGET que não estão em mavros. Vou corrigir isso como parte da refatoração de código que queremos fazer para os plug-ins de ponto de ajuste. Além disso, para esses fluxos de destino do controlador, você precisa transmiti-los explicitamente no lado PX4.
O controle offboard é experimental e este plugin não foi testado, então não tenho certeza de onde as coisas deram errado ainda. Eu preciso de mais dados.

Desculpe, certo, estava ocupado fazendo alguns voos DAQ.
Portanto, ATTITUDE_TARGET soa exatamente como preciso para ter certeza de que o pixhawk está tentando obter os comandos do joystick que estou enviando. Eu tenho um 3DR, pixhawk com um computador maior montado a bordo (pilha px4 funciona fabulosamente aliás, faltando apenas alguns modos de vôo).

Posso dar uma olhada nisso ou você tem um fork com isso implementado?

@pmukherj Estou procurando obter alvos de atitude e posição em meu plug-in do visualizador. Existem alguns problemas de tf, então estou resolvendo-os.
Qual computador companheiro de bordo você está usando?
Em relação às metas, você realmente não precisa implementar nada. Basta usar a ponte UDP que temos nos mavros e corrigir um link para o QGC em seu computador de desenvolvimento. Você pode visualizar e plotar tudo lá.

Desculpa! Mudança de escritórios no ano novo.
Estou testando com todos os tipos de computadores (odroids, TK1's etc.). Vou tentar usar uma ponte UDP.
Suponho que posso usar qualquer uma das conexões de telemetria no pixhawk? Além do computador que acompanha, também tenho uma conexão sem fio em uma das portas de telemetria (como é padrão no pixhawk 3DR).

Sim. Verifique se os pontos de ajuste estão realmente funcionando! Os pontos de ajuste internos estão aceitando isso e as saídas do controlador também são visíveis. Agora, para testes de vôo :). Me deseje sorte.

@pmukherj Você pode conectar o companheiro à sua porta TELEM2 e iniciá-lo via extras.txt no seu cartão microSD.
É bom que os pontos de ajuste estejam funcionando. Boa sorte com os voos.
Verifique: http://www.pixhawk.org/dev/ros/mavros_offboard
Na parte inferior há uma linha de código em branco, onde você deve adicionar o comando mavros que você usou para mudar para o modo offboard (como uma opção para as pessoas se quiserem)

Além disso, você pode adicionar o pedido de teste de voo aqui: http://www.pixhawk.org/dev/offboard_control/testing

Basta colocar as pontas e eu limparei tudo.

@vooon O plugin do joystick funciona bem, mas trava muito se um dos eixos não for encontrado ou estiver fora de alcance, etc.

Podemos adicionar o limite mínimo / máximo.

Observe que não era um plugin, nó.

Verdade ;)
Acho que vou fazer isso como um plugin, já que o script / python parece um tanto confuso + não confiável.

Não quero o plugin porque ele está reinventando a roda. Reescrita máxima de Python para C ++.
Mas realmente não é necessário quando o mavteleop é executado no desctop e controla os mavros do OBC.

@vooon , você já pensou em uma maneira de resolver isso ?