Neputs/IMC/ROS - try 2

[Đula Nađ]

Hi guys,

since there was no answer to any of the questions a couple of months ago, I'll try again with a more specific approach.

I took a closer look at Neptus and DUNE source the other day. It could take me quite some time to go through the Neptus code and determine how to write a ROSJava comm plugin so without any additional info I will not bother with that.

However, I used the DUNE IMC layer to connect our vehicle and simulator through a ROS node to Neptus for location indication. Turned out quite simple and straight forward to repack the messages.

We already have a Neptus mission parser for ROS that we used for a while to plan missions for our vehicles. I would like to do that directly through the IMC connection with ROS. 

Do I need also TCP/IP for that ? (I don't get anything on the UDP port when I press upload)

What is the minimum data the node should send to Neptus in order to get and verify the missions through the IMC channel ?

As for the IMC-ROS bridge. I tried generating the ROS messages from the XML which seems to work fine, at least for the messages I tried (EstimatedState, EntityState, ...). I also tried extending the DUNE::IMC message classes with ROS message traits so that I can directly repack the message on arrival and post it to Neptus and back. Seems to work fine with little effort. The message traits could also be generated automatically. 

Does anyoine think there is any use for such a simple bridge ?

[Ricardo Martins]

Hi Đula,

Sorry for our silence, next time we will be more responsive. I will have a meeting with our developers and reply to your email tomorrow. In the meantime, do you want to have your code included upstream ?

--
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchai...@googlegroups.com.
Visit this group at http://groups.google.com/group/lsts-toolchain.
To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/1ef24255-aebf-4ff7-b189-edc4ed717dab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Đula Nađ]

Hi Ricardo,

If by upstream you mean the dune repository, there are no changes needed to that source code. By extending I meant I specialized the ROS message traits for the IMC message classes (http://wiki.ros.org/roscpp/Overview/MessagesSerializationAndAdaptingTypes). This is just so that I can deserialize the IMC ROS message format into it's corresponding IMC DUNE message class.

However, I can upload this test concept to a github repo (https://github.com/labust/ros-imc-bridge) when I make it a bit more presentable some time next week. The code I used the other day is already in the repo.

As for the scripts to generate all the messages, traits, etc. from the XML definition I would need to write them and make some tests with more complex messages when I have the time. Currently, I just added few lines of code to your python script to drop IMC msg id and member variables to ROS *.msg files during my testing.

[Ricardo Martins]

Dear Đula Nađ,

Answers inline.

On Thu, Jun 12, 2014 at 7:44 AM, Đula Nađ <dula...@gmail.com> wrote:

Hi Ricardo,

If by upstream you mean the dune repository, there are no changes needed to that source code. By extending I meant I specialized the ROS message traits for the IMC message classes (http://wiki.ros.org/roscpp/Overview/MessagesSerializationAndAdaptingTypes). This is just so that I can deserialize the IMC ROS message format into it's corresponding IMC DUNE message class.

However, I can upload this test concept to a github repo (https://github.com/labust/ros-imc-bridge) when I make it a bit more presentable some time next week. The code I used the other day is already in the repo.

As for the scripts to generate all the messages, traits, etc. from the XML definition I would need to write them and make some tests with more complex messages when I have the time. Currently, I just added few lines of code to your python script to drop IMC msg id and member variables to ROS *.msg files during my testing.

Thanks for letting us known. How are you handling inline messages and message lists ?

 

On Wednesday, June 11, 2014 11:40:41 PM UTC+2, Ricardo Martins wrote:

Hi Đula,

Sorry for our silence, next time we will be more responsive. I will have a meeting with our developers and reply to your email tomorrow. In the meantime, do you want to have your code included upstream ?

On Wed, Jun 11, 2014 at 10:36 AM, Đula Nađ <dula.nad@gmail.com> wrote:

Hi guys,

since there was no answer to any of the questions a couple of months ago, I'll try again with a more specific approach.

I took a closer look at Neptus and DUNE source the other day. It could take me quite some time to go through the Neptus code and determine how to write a ROSJava comm plugin so without any additional info I will not bother with that.

However, I used the DUNE IMC layer to connect our vehicle and simulator through a ROS node to Neptus for location indication. Turned out quite simple and straight forward to repack the messages.

We already have a Neptus mission parser for ROS that we used for a while to plan missions for our vehicles. I would like to do that directly through the IMC connection with ROS. 

Do I need also TCP/IP for that ? (I don't get anything on the UDP port when I press upload)

What is the minimum data the node should send to Neptus in order to get and verify the missions through the IMC channel ?

First you must add your vehicle to Neptus, see https://github.com/LSTS/neptus/wiki/Adding-a-new-vehicle. Then you need to advertise your vehicle (see message Announce) using UDP multicast (address 224.0.75.69) and broadcast to ports 30100, 30101, 30102, 30103, and 30104. That way Neptus will know where to send the missions. If you have doubts checks DUNE's implementation of this feature:

https://github.com/LSTS/dune/blob/master/src/Transports/Announce/Task.cpp

 

As for the IMC-ROS bridge. I tried generating the ROS messages from the XML which seems to work fine, at least for the messages I tried (EstimatedState, EntityState, ...). I also tried extending the DUNE::IMC message classes with ROS message traits so that I can directly repack the message on arrival and post it to Neptus and back. Seems to work fine with little effort. The message traits could also be generated automatically. 

Does anyoine think there is any use for such a simple bridge ?

We would like to integrate this functionality in DUNE, if you can contribute with patches or pull requests we would be glad to integrate them. However, for the foreseeable future Neptus will remain an IMC only system, as we lack the man-power to develop support for ROS messages.

 

--
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchai...@googlegroups.com.

Visit this group at http://groups.google.com/group/lsts-toolchain.
To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/1ef24255-aebf-4ff7-b189-edc4ed717dab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchai...@googlegroups.com.
Visit this group at http://groups.google.com/group/lsts-toolchain.

To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/65cda7fc-9683-4795-90ad-dec219430cd7%40googlegroups.com.

[Đula Nađ]

Hi Ricardo,

the answers are below.

"How are you handling inline messages and message lists ?"

I don't, yet. I used it for a small subset of messages that we needed for the UROS project and to interface the basic feedback from our vehicle. 

Hopefully I can think about that later next month when I am back at the office. More complex structures could be emulated by a ROS node and sent as a std_msgs/String to a UDP bridge. It is not as fancy as "automatic" ROS to IMC message translation but is more straight forward.

I already have the vehicle shown in Neptus as in "Service". I am not doing the full broadcast however so that could be the problem. Thanks for the info I will take a look at that.

When I have something I'll issue a pull request so that you can take a look.

Best regards,

Đula

[Ricardo Martins]

On Sat, Jun 21, 2014 at 11:35 AM, Đula Nađ <dula...@gmail.com> wrote:
> Hi Ricardo,
>

> the answers are below.
> "How are you handling inline messages and message lists ?"
> I don't, yet. I used it for a small subset of messages that we needed for
> the UROS project and to interface the basic feedback from our vehicle.
> Hopefully I can think about that later next month when I am back at the
> office. More complex structures could be emulated by a ROS node and sent as
> a std_msgs/String to a UDP bridge. It is not as fancy as "automatic" ROS to
> IMC message translation but is more straight forward.
>
> I already have the vehicle shown in Neptus as in "Service". I am not doing
> the full broadcast however so that could be the problem. Thanks for the info
> I will take a look at that.
>
> When I have something I'll issue a pull request so that you can take a look.

Thanks.

> https://groups.google.com/d/msgid/lsts-toolchain/0d15e573-af24-4547-8d9e-48ce6af17817%40googlegroups.com.