-
Notifications
You must be signed in to change notification settings - Fork 96
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
Comments
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.
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. |
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 |
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 |
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. |
We want to use the simulated environment mainly to test communication and the safety of drones during formation changes. |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: