Volume = 2.0000, 0.1100, 0.1100

[hash24751]

Hello friends, I wanted to know this value in the vsim models configuration file: Volume = 2.0000, 0.1100, 0.1100. What does it mean? Is it the size of the vehicle or its dimensions, or what exactly?

[josebraga]

Does are the dimensions, in meters. It's for a torpedo shaped AUV

[hash24751]

Thank you. Can I connect the dune & neptus system to the gazebo to display the vehicle’s movement in 3D?

[josebraga]

Thank you. Can I connect the dune & neptus system to the gazebo to display the vehicle’s movement in 3D?

Sorry, I am not familiar with gazebo. There's a project in github lauv-gazebo, not sure if that's what you want

[manushashim2025]

Ok so now that I have completed the configuration files and simulation with Neptus, do I transfer the files to a piece like Raspberry Pi or are there other steps?

[josebraga]

What is your vehicle if I may ask? What type of system is it?

To run on a real system you will have to compile dune into a target for the system you want, and adapt (add drivers or modify configurations) the hardware drivers so dune is able to interact with the parts you want it to command.

I'd expect it will require quite an amount of work

[manushashim2025]

My vehicle is an AUV that is somewhat similar to the LAUV and I want to use the Dune control system with the Neptus interface

[manushashim2025]

@josebraga Is it likIs it like connecting different sensors, imu and depth sensor, if it is not known in the tasks in the dune, how do I know it, for example?

[josebraga]

Isn't this a vehicle you know the parts of ? DUNE drivers have the name/model of the hardware part in the name of task. So that clues you in to what sensor or actuator that SW version was developed for. Of course, protocol versions are subject to change, so even if the hardware match you will have to check firmware/protocol versions - I guess you can reach out to the current team at LSTS to know specific versions if you need.

But if you have completely different sensors, it won't be plug n play, you will have to program it, or get some libraries.

I don't know anything about the system you have, so I don't think I can help further

[manushashim2025]

@josebraga If I have an MS5803 depth sensor and the depth sensor is Keller in the driver task , will the system deal with it or does it need an interface like Arduino or does it need to write a driver in the original code to read the sensor?

[josebraga]

I have no idea 🤷
Please stop tagging me with those types of questions. I am not involved in the project for +10y, I can provide some very high level help, but not specifics.

[Bernardo-Gabriel]

Thank you. Can I connect the dune & neptus system to the gazebo to display the vehicle’s movement in 3D?

Check this #274 (comment) out, it may he helpful.

---

@josebraga Is it likIs it like connecting different sensors, imu and depth sensor, if it is not known in the tasks in the dune, how do I know it, for example?

As mentioned, the drivers currently available on DUNE are designed for specific devices, targeted for specific hardware and software versions. Some are compatible with different devices, but most of them aren't (for example, the Sensors/GPS task may work with different GPS devices, as long as they use the same NMEA messages, on the other hand, the Sensors/LIMU task was designed for a device LSTS developed, with a proprietary protocol, making it not compatible with other IMUs).
You may need to program a new driver for the sensors you are using.

---

@josebraga If I have an MS5803 depth sensor and the depth sensor is Keller in the driver task , will the system deal with it or does it need an interface like Arduino or does it need to write a driver in the original code to read the sensor?

I don't think the Sensors/Keller task will be compatible with the MS5803 depth sensor you are using.
If you want to program a driver for that sensor, you will need to study the sensor datasheet and understand how you can access the data. You will need a task that acquires the data, parses it, and then dispatches the data as an IMC message.
You can choose to design your driver communicating directly to the sensor (using UART/USART port, I2C, SPI, ...), acquiring the data, and parsing it. Or if it is more convenient, you could use an Arduino (or something similar) as an interface. Use the Arduino to acquire the data and send it to the CPU using a serial port. Then, you will need a task that handles the serial ports and parses the data from the Arduino (this approach may be easier, as there may be an Arduino library for that sensor).

---

Please, in the future, avoid talking about different topics on the same issue. I understand your frustration about very few replies (or even no replies), but it's easier if you create different issues for different topics.