Uuv_simulator: <neutrally_buoyant>tag não faz nada.</neutrally_buoyant>

Oi,

obrigado por relatar, vou verificar isso. Enquanto isso, você pode ter seu veículo positivamente flutuante se definir a bandeira neutrally_buoyant para zero e definir o volume, como no modelo rexrov https://github.com/uuvsimulator/uuv_simulator/ blob / master / uuv_descriptions / models / rexrov / urdf / rexrov.gazebo.xacro # L32.
O volume é então usado para calcular o vetor de força de empuxo.

Olá,

Tentei definir o volume para ser bem alto. Não tão grande quanto rexrov , e ainda estava afundando. Vou tentar isso e voltar para você, mas tentei aumentar meu volume e diminuir minha massa para forçá-lo a flutuar. Entrarei em contato com você com os resultados em um segundo.

Então eu ajustei meu volume para 3.1093918 m3 e minha massa para 0.123497 , e meu veículo ainda afundou. Posso tentar definir exatamente o que você tem rexrov definido para seu volume e até mesmo definir a tag <box> para o que o rexrov tinha, bem como seu modelo hidrodinâmico . Portanto, não sei onde verificar um problema.

Você definiu <neutrally_buoyant>0</neutrally_buoyant> ?

@musamarcusso Eu tentei definir <neutrally_buoyant> para 0 e 1 . Nenhuma mudança real.

Olá @atomoclast , é este o veículo que deseja modelar?

http://www.videoray.com/images/specsheets/2016/2016_P4STANDARDBASE_FINAL.pdf

Vou tentar substituir esses parâmetros aqui para reproduzir isso.

@musamarcusso Sim, este é o veículo que estou tentando modelar.

Eu tenho um arquivo mesh, se você precisar.

Acabei de tentar lançar uma caixa de teste com o que entendi ser o plug-in de flutuabilidade e tentei com a tag neutrally_buoyant definida como 0 e também como 1 e a caixa ainda afundou ambas as vezes. Ele também estava imprimindo o erro [Wrn] [UnderwaterObjectPlugin.cc:207] Relative angular acceleration is invalid -nan repetidamente.

Eu tenho os dois arquivos abaixo para você revisar. Não tenho certeza qual é o problema. Eu adicionei a extensão .txt para que eu possa fazer o upload do comentário.

box.urdf.txt
upload_box.launch.txt

Assim que você ver o erro Relative angular acceleration is invalid nosso UnderwaterObjectPlugin não aplicará mais nenhuma força ou torque, já que este é um claro indicador de que o motor de física está quebrado.

Eu dei uma olhada na definição de sua caixa:

<inertia ixx="0" ixy="0" ixz="0" iyy="0" iyz="0" izz="0" />

Esse é o culpado. Nenhum corpo rígido deve ter momentos de inércia nem massa zero. Por causa da maneira como o Gazebo calcula as acelerações de forças / torques, isso resultará em uma divisão por zero.

Informe-nos se isso resolve o seu problema.

@sebastianscherer Isso faz todo o sentido. Acabei de usar um elipsóide básico para estimar minha inércia para o meu veículo, e ele está flutuando agora.

Vamos descobrir o plugin Thruster! Também estou tendo alguns problemas.

No terminal do gazebo eu vejo:

[Msg] Thruster #0 initialized
[Msg]   - Link: videoray_pro4/thruster_0
[Msg]   - Robot model: videoray_pro4
[Msg]   - Input command Gazebo topic: /videoray_pro4/thrusters/0/input
[Msg]   - Thrust output Gazebo topic: /videoray_pro4/thrusters/0/thrust
[Msg] Thruster #1 initialized
[Msg]   - Link: videoray_pro4/thruster_1
[Msg]   - Robot model: videoray_pro4
[Msg]   - Input command Gazebo topic: /videoray_pro4/thrusters/1/input
[Msg]   - Thrust output Gazebo topic: /videoray_pro4/thrusters/1/thrust
[Msg] Thruster #2 initialized
[Msg]   - Link: videoray_pro4/thruster_2
[Msg]   - Robot model: videoray_pro4
[Msg]   - Input command Gazebo topic: /videoray_pro4/thrusters/2/input
[Msg]   - Thrust output Gazebo topic: /videoray_pro4/thrusters/2/thrust
[Msg] JointStatePublisher::robotNamespace=videoray_pro4

No terminal do propulsor, vejo:

process[videoray_pro4/thruster_allocator-1]: started with pid [26422]
[INFO] [1500390755.909692, 0.000000]: ThrusterManager::update_rate=50
output_dir= /home/andrew/Development/ underwater_ws/install/share/videoray_description/config/videoray_pro4
ThrusterManager: updating thruster poses
conversion_fcn= proportional
conversion_fcn_params= {'gain': 0.00031}
transform: /videoray_pro4/base_link -> /videoray_pro4/thruster_0
could not get transform from: /videoray_pro4/base_link
to: /videoray_pro4/thruster_0
[]

Acabei de executar rosrun tf view_frames e esta foi a saída. Vejo que a árvore TF mostra uma transformação entre o base_link e o propulsor ...
frames.pdf

Os frames entre o mundo e o base_link do veículo são gerados pelo nó message_to_tf , que faz parte do pacote hector_localization . O exemplo de arquivo de lançamento do modelo RexROV é este

https://github.com/uuvsimulator/uuv_simulator/blob/master/uuv_descriptions/models/rexrov/launch/upload_rexrov_default.launch#L31

Como você afirmou isso no arquivo de inicialização?

@musamarcusso De acordo com o tutorial wiki, chamei a transformação da seguinte maneira:

<!-- Publish state and tf for in relation to the world frame -->
            <group ns="$(arg namespace)">
                <node name="ground_truth_to_tf" pkg="message_to_tf" type="message_to_tf" output="screen">
                    <param name="odometry_topic" value="/$(arg namespace)/pose_gt" />
                    <param name="frame_id" value="/$(arg world_frame)" />
                    <param name="tf_prefix" value="$(arg namespace)" />
                </node>
            </group>

Parece diferente da linha que você mencionou acima. Vou tentar isso agora.

Você pode tentar substituir o bloqueio que você me enviou por este

<include file="$(find uuv_descriptions)/models/common/launch/message_to_tf.launch">
    <arg name="namespace" value="$(arg namespace)"/>
</include>

Se essa correção funcionar, corrigirei o tutorial imediatamente.

Tentei substituir meu bloco pelo seu, mas não funcionou. A única maneira de funcionar foi os dois blocos chamados juntos.

VelocityControllerNode: initializing node Thruster #0 - proportional - thrusters/0/input transform: /videoray_pro4/base_link -> /videoray_pro4/thruster_1 Thruster #1 - proportional - thrusters/1/input transform: /videoray_pro4/base_link -> /videoray_pro4/thruster_2 Thruster #2 - proportional - thrusters/2/input transform: /videoray_pro4/base_link -> /videoray_pro4/thruster_3 could not get transform from: /videoray_pro4/base_link to: /videoray_pro4/thruster_3 [<uuv_thrusters.models.thruster_proportional.ThrusterProportional object at 0x7efc4bdb8a50>, <uuv_thrusters.models.thruster_proportional.ThrusterProportional object at 0x7efc4bdb8c10>, <uuv_thrusters.models.thruster_proportional.ThrusterProportional object at 0x7efc4bd4c190>] TAM= [[ 1. 0. 0. ] [ 0. 0. 0. ] [ 0. 0.99999968 0.99999968] [ 0. 0.09999997 -0.09999997] [ 0.1 0.15249995 0.15249995] [ 0. 0. 0. ]] ThrusterManager: ready ThrusterManager: ready
Agora preciso ver por que ele não consegue obter o TF do propulsor 3.

Consigo lançar minha versão do joy_velocity.launch , mas não consigo controlar o veículo com meu controlador.

Tenho tentado depurar coisas e estou comparando as saídas da visualização rqt_graph dos nós. Estas são as duas redes que estou vendo. Não sei por que não está funcionando exatamente.

Outra atualização que acabei de perceber:

Wiki clama: <xacro:property name="prop_mesh_file" value="file://$(find uuv_descriptions_example)/models/rov_example/mesh/propeller.dae"/>

Deve ser: <xacro:property name="prop_mesh_file" value="file://$(find uuv_descriptions)/models/rexrov/mesh/prop.dae"/>

Olá @atomoclast ,

não, está correto no tutorial. O exemplo no tutorial não é um exemplo funcional, é por isso que coloquei este README.md na pasta mesh, então este prop_mesh_file tem que ser editado pela pessoa que está fazendo o novo modelo do veículo.
O joy_velocity é definido por padrão para o mapeamento do controlador XBox. Qual é o modelo de controlador que você tem?
Você tem seus arquivos em algum lugar do Github? Eu poderia tentar executá-lo e dar um feedback.

@musamarcusso Eu https://github.com/atomoclast/videoray_description/tree/feature/DEEP-291

Olá @musamarcusso , você já deu uma olhada neste repositório?

Sim, eu clonei. Vou dar um feedback mais tarde hoje.