I want to control RTF through a ground station which scripts are ran on, so I connect the two devices as such, with 192.168.137.227 being the RTP's IP:
However, it was not successful as shown in the following image:
It did work when I tried changing wait_ready=True to wait_ready=False, so it seemed like there were problems when populating default parameters. The connection setup is basically the same as the ones shown in Autonomous Drone Engineer tutorials, connecting via tcp to port 5760. I have also changed the timeout duration to 2 minutes in the source code, and the error still occurred.
I need some help with debugging the issue, thanks a lot!
Thank you for contacting Intel Technical Support.
Your request has been received and is currently being investigated.
We will get back to you as soon as possible.
Thank you for your patience.
We tested the Dronekit example and we obtained the same error at first. The thing we did to fix the error was change the IP address in the sample code.
Also, please tell me if you are using the latest aero image and bios.
You can find them in the link below if you need to download them:
Hi Intel Corporation,
Thank you for the investigation!
Here is the status of the components on my Intel Aero:
BIOS_VERSION = Aero-01.00.13
OS_VERSION = Poky Aero (Intel Aero Linux Distro) 1.6.0 (pyro)"
AIRMAP_VERSION = 1.8
FPGA_VERSION = 0xc1
AeroFC firmware version = 1.6.5
I believe they are all most updated.
Currently in my code, the IP address I used is intel aero's virtual IP when it was connected to the same network as my ground station's.
Could you clarify which IP address or what type of IP address(e.g. Static IP) you changed to to resolve the problem?
From looking at the aero version, we can see that some components are not the latest. The latest image is v1.6.1 and the FPGA version should be 0xc2. You can find the download links below:
Aero comes with 3 FPGA firmwares that can be used, all of them under the
aero-rtf.jam: this is for use with RTF
aero-rtf-recovery.jam: this is for use with the RTF under special circunstances: it allows Aero to instruct the flight controller to stop on bootloader so we can flash new versions of the firmware even if the firmware stops responding due to a bad update
aero-compute-board.jam: this should be selected if using only the compute board. Note that the labels that accompany the compute board have no meaning. Check the official documentation for each pin.
Flash the new FPGA firmware:cd /etc/fpga/ jam -aprogram .jam
is one of the firmwares above.
When using the RTF as an access point, we used the default IP which is 192.168.8.1. When we connected to a router, we used the IP that the router assigned the Aero RTF. For this to work, you need to make sure the mavlink router is turned on. To check the status of mavlink, you can type:
systemctl status mavlink-router
If the status of mavlink is inactive, then you can turn it on by typing the following command:
systemctl start mavlink-routerHope this helps.
Sorry about that, I have updated the components, the OS and the FPGA:
The first time I ran the script after reinstalling, there was no timeout issue but just some exceptions related to heartbeat, and the vehicle could arm and disarm. However, latter attempts all failed with the same timeout issue, so I reinstalled the OS again. Still, the problem remained. I did check mavlink status repeatedly during the process, and it was active as shown in the image:
From looking at the TCP connection history, I guess that the connections were accepted whenever I ran my script, but for some reasons the connections closed again.
I will keep investigate further into the problem. May I ask which versions of pymavlink and DroneKit are you using when testing?
Thanks a lot!
I borrowed and tried with another Aero, updating its components to the latest too. It did not have any timeout issues, except the first attempt which I guess it was because that the vehicle was still initializing something after it just booted. The exception related to heartbeat was the same as the one I mentioned in the previous reply. Also I am not quite sure why is GUIDED an unknown mode. I have also tried with OFFBOARD mode. Though it did not say unknown mode "OFFBOARD", the line "mode 100925440 not available on mavlink definition" did appear.
Anyway, the timeout issue was solved! I will try reinstalling things on my Aero again, and see if the problem still occurs.