Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a hardware interface to the ArduPilotPlugin #128

Open
boom6314 opened this issue Nov 27, 2024 · 7 comments
Open

Add a hardware interface to the ArduPilotPlugin #128

boom6314 opened this issue Nov 27, 2024 · 7 comments
Assignees
Labels
enhancement New feature or request

Comments

@boom6314
Copy link

Feature request

I am currently working on a multi-drone formation algorithm. I will convert the algorithm results into coordinates to make the drone perform formation transformation, which includes three-dimensional formation. During the simulation process, in order to be closer to the real world, I want to use a real flight control board. I searched and found out Currently, Ardupilot does not support HITL. Currently, I am using "Simulation on Hardware", so I followed the instructions on the Ardupilot website and successfully completed "Simulation on Hardware" and generated a virtual drone. But it's like I mentioned earlier that my performance method includes three-dimensional formations, and I am not sure whether the Ardupilot SITL environment is reliable enough, so I want to connect the virtual drone generated through "Simulation on Hardware" to Gazebo.

Describe the solution you'd like

One method I am currently thinking of is to add a hardware interface to the ArduPilotPlugin, such as /dev/ttyACM, baud:115200, so that the drone generated through 'Simulation on Hardware' can be connected to Gazebo

Describe alternatives you've considered

I did a little research on the program code, and I found that Gazebo seems to use address:127.0.0.1 port:9002 to transmit information when connecting to SITL. So I tried using mavproxy's command mavproxy.py --master=/dev/ttyACM0 --baudrate 115200 --out udp:127.0.0.1:9002 --console However, it seems useless. The model in Gazebo will not act according to the commands I input.

Platform
[ ] All
[ ] AntennaTracker
[ v ] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Additional context
You can see in the console of mavproxy that I can use command to control the drone, but the model in Gazebo has no movement.

Screenshot from 2024-11-27 23-00-32

@srmainwaring
Copy link
Collaborator

Hi @boom6314, I'm not sure that I follow the reasoning for wanting to run the SITL part of the simulation on a FC rather than a PC.

performance method includes three-dimensional formations, and I am not sure whether the Ardupilot SITL environment is reliable enough

Which aspect of the simulation performance are you concerned about? Is it the response of the flight controller or the physics? Even if the flight control is run on hardware rather than on a PC, the physics engine controlling the flight dynamics is still in Gazebo.

I have not attempted to run simulation on hardware, I expect there may need to be some modification on the AP side to incorporate the SITL JSON engine if it's not available already. But before I look into that I'd like to better understand the concerns you have about performance and what you think may be different by using a FC to run the control code before allocating time to it.

@srmainwaring srmainwaring added the enhancement New feature or request label Nov 27, 2024
@srmainwaring srmainwaring self-assigned this Nov 27, 2024
@khancyr
Copy link
Collaborator

khancyr commented Nov 27, 2024

As Rhys said, there are some misconceptions there. HITL just use the hardware CPU to run the code. It isn't better nor brings value in the multi drone case.

Starting your test with normal SITL without gazebo would be the first step. That would allow fast and reproducible tests without pain. SITL is easy modifiable and adding some watcher to look at potential collision is straight forward.

On second step you could use Gazebo to have more advanced feedback on collision but that shouldn't be needed if the first step is done correctly.

The GUI aka the Gazebo view shouldn't be irrelevant as only the data count and not the display... And multi drone gazebo will need far more resources anyway

@boom6314
Copy link
Author

Hello @srmainwaring , @khancyr thank you for your replies. Sorry, I am replying so late because of the time difference here.

In fact, my initial understanding of HITL was to use the Senors of the real flight control board to receive information in a simulation software with a physics engine and calculate and run the formation algorithm through the processor of the real flight control board. However, when I searched some information, I found that HITL is not what I thought. Sensors such as IMU and GPS are actually built in the world of Gazebo. As you said, the physics engine and sensors that control flight dynamics still exist in Gazebo.

In my previous research, I simply used SITL to simulate my algorithm. However, when I used the flight control board for actual flight, some minor situations always occurred and the flight results were slightly different. Dealing with these situations will actually consume a lot of our time. I think it's possible that I didn't add environmental interference factors into the simulation, and the computing power of the flight control board's processor and the computer are still different. That I want to try to match our real flight conditions during simulation, such as environmental interference factors (like wind interference) and the results of flight control board calculations.So I want to use my real flight control board processor in a simulated environment and
I also know that SITL can set wind interference, but I'm not sure its physics engine can be as good as 3D simulation software like Gazebo.

@srmainwaring
Copy link
Collaborator

In my previous research, I simply used SITL to simulate my algorithm. However, when I used the flight control board for actual flight, some minor situations always occurred and the flight results were slightly different.

This will be the case for almost any simulation. Different simulators supported by ArduPilot have different capabilities, and the usual approach is to select the one that best captures the thing you are trying to model. For good aerodynamics RealFlight seems to be favoured, for multiple vehicles and interaction with other objects: Gazebo, for visual fidelity: AirSim. For immediate ease of use and the bulk of testing: SITL.

The key is to list down the features that are important for the test that is being undertaken, and then select and configure a simulator that best meets them. We can help with that, but need the test criteria first.

@boom6314
Copy link
Author

We want to use the simulated environment mainly to test communication and the safety of drones during formation changes.
We want to test whether the coordinates calculated by our algorithm can be transmitted to the real flight control board through external communication equipment. Whether the real flight control board has the ability to process the information we transmit. Next, during the formation change, Will our drones collide with each other? This is the biggest reason why I want to connect it to Gazebo. Because Gazebo has collision detection and physics engine.
As I mentioned above, I want to connect multiple virtual machines generated by "Simulation on Hardware" to Gazebo so that I can input commands to operate the virtual drones through tools such as Mavproxy or Mavros.

@srmainwaring
Copy link
Collaborator

I'm afraid I'm still not seeing any reason to use simulation on hardware for this case, unless you believe the processing power of the actual FC is not sufficient for requirements (which seems unlikely). In any case that would be better tested as a standalone study rather than a fully integrated Gazebo sim.

If there are environment and sensor noises that you think should be included in the Gazebo environment that is something that can be addressed - mostly by adjusting configuration. But I am not convinced that wiring up Gazebo to a real FC is needed for your study.

I suggest that you set up the Gazebo environment required to conduct the multi-drone study, and if it turns out that the SITL FC's are really not suitable then we can revisit. Setting up the multi-drone environment and arranging all the inter-drone comms is already non-trivial and is required in both the standard usage of Gazebo and the proposed sim on HW, so that should be the first step.

@boom6314
Copy link
Author

In any case that would be better tested as a standalone study rather than a fully integrated Gazebo sim

Do you mean I should separate communication and algorithm simulation?

I have already set up the Gazebo environment, but in terms of communication, I want to test our communication module.
Can SITL's drones transmit data to each other through xbee? In terms of hardware, we want to install xbee on the telemetry interface on the flight control board of each drone so that each drone can receive or transmit information. I don't know is there any way SITL can do this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants