- Joined
- Mar 21, 2016
- Messages
- 249
- Reaction score
- 75
This is a work in progress but just wanted to share my findings so far. The end goal is to do the following:
Findings:
When the Solo Simulator starts up, it SSHes into the hardcoded IP of 10.1.1.1 which is the controller and then runs the following command:
This tells the controller that the Solo will be at the IP address contained in the solo.ip file.
Based on /etc/inittab, one can discover what each init (runlevel) does:
At this point, it switches over to UDP and sends commands back to the controller, presumably to update the telemetry displayed on the controller.
The strange thing is when I interact with the controller, I do not see any data coming off of the controller yet it moves the virtual Solo in the Simulator just fine. I feel I am missing something while sniffing the traffic in between.
Notes:
- I noticed that the Simulator possibly uploads a listener to the controller during the SSH connection but this is unconfirmed.
- When the controller loses connection to the Solo Simulator such as closing the app for example, the controller tries to ping the device over port 5005. The same port is listening on the controller for other devices to ping the controller.
- The controller, not surprisingly, runs what appears to be a master MAVLink on port 14550. This info is based on netstat.
__
You can see the MAVLink communication between the controller and the virtual Solo in the simulator by issuing the following command on your computer:
I am probably missing an obvious step such as passing in an --out parameter to communicate back to the Solo Simulator but at the moment, I cannot issue commands like arm throttle, takeoff 10, etc. The only thing you can do is just issue read commands such as status.
__
This is all I have for now. Please feel free to contribute or check back later!
- Use 3DR Controller with PC (Useful for those drone simulators such as DRL that let you use a real controller)
- Simulate a 3DR Controller for 3DR's Solo Simulator app (This one is tricky because the IP is hardcoded to use 10.1.1.1 and must succeed otherwise app fails)
Findings:
When the Solo Simulator starts up, it SSHes into the hardcoded IP of 10.1.1.1 which is the controller and then runs the following command:
Code:
init 2; echo [IP OF DEVICE RUNNING SIM] > /var/run/solo.ip; init 4
Based on /etc/inittab, one can discover what each init (runlevel) does:
Code:
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevel 2 is multi-user.
# Runlevel 3 is STANDBY (controller/solo not paired).
# Runlevel 4 is READY or FLIGHT (all flight code running).
# Runlevel 5 is MAINTENANCE.
# Runlevel 6 is reboot.
At this point, it switches over to UDP and sends commands back to the controller, presumably to update the telemetry displayed on the controller.
The strange thing is when I interact with the controller, I do not see any data coming off of the controller yet it moves the virtual Solo in the Simulator just fine. I feel I am missing something while sniffing the traffic in between.
Notes:
- I noticed that the Simulator possibly uploads a listener to the controller during the SSH connection but this is unconfirmed.
- When the controller loses connection to the Solo Simulator such as closing the app for example, the controller tries to ping the device over port 5005. The same port is listening on the controller for other devices to ping the controller.
- The controller, not surprisingly, runs what appears to be a master MAVLink on port 14550. This info is based on netstat.
__
You can see the MAVLink communication between the controller and the virtual Solo in the simulator by issuing the following command on your computer:
Code:
mavproxy.py --master=0.0.0.0:14550
I am probably missing an obvious step such as passing in an --out parameter to communicate back to the Solo Simulator but at the moment, I cannot issue commands like arm throttle, takeoff 10, etc. The only thing you can do is just issue read commands such as status.
__
This is all I have for now. Please feel free to contribute or check back later!
Last edited: