Hi @AlexPapadimitriou thanks for sharing the results. From the video it looks like the CAN bus was healthy. The second port will timeout as its not connected. The first one’s timeout count doesn’t seem to increase over the course of connection. And the initial count will be from startup.
Regarding the IERR, i will investigate and get back to you on that.
For the issue with dronecan_bridge.py. Please make sure that pydronecan is up to date, version >=1.0.26
Also when you publish messages over vcan do you see any loss in RTCM messages, it feel like the messages are not there from the source itself, also which interface is the dronecan gui tool connected through?
Thanks for pointing out the correct version of dronecan. I’m attaching the logs from both the can interface I’m using (can2) and the virtual can (vcan0). However, I’m not sure I understand the necessity of vcan in the first place. I don’t notice any difference of using vcan over the socketcan interface. I tried connecting DroneCAN GUI tool to both can2 and vcan without noticing any changes in the behavior of RTCM messages. dronecan_logs.zip (2.3 MB)
I noticed that I’m missing mostly the larger messages (smaller are missing too, but less frequently). So I’d like to describe the way I’m handling them and if possible you could verify if my reasoning is correct. So, messages larger than 128 are splitted into chuncks of 128. E.g., an RTCM packet with ID 1077 and length 510 is splitted into 4 chuncks (3 x 128 + 1 x 126). Each chunk is broadcasted by the UAVCAN publisher and the next message follows. Do I need to send something in between to indicate that all chunks of the message have been broadcasted?
@AlexPapadimitriou I looked into logs you provided and it seems like that chunks of RTCM packets are missing. It seems like there is an issue on your end preventing pushing all the packets. Few things to verify would be to check you have large enough transmit buffer, and are not running out of allocated space for transmit. Verify this by putting debug prints in your code to check this. Make sure your memory pool size is large enough and that you are calling node spin regularly.
Hi @sidbh, thanks for pointing these out. It turns out that calling the spin every 1ms instead of 10ms seems to solve the issue. The corrections appear steadily on the RTK Panel. However, I only managed to get RTK Float and never got RTK Fixed, even when using a base station located at a distance of ~30 km away from my location and the GPS was locked to 18 satellites. Is that a normal behavior?
@AlexPapadimitriou so Here4 is a dual band GNSS with L1 & L5, but I suspect you are only receiving corrections for L1 & L2. That will impact the performance. But you should still be able to get into RTK Fixed with just L1 corrections though, it may just take a bit longer to get Fix than if you had both L1 & L5 corrections. Also even though it may feel like all corrections are making through, that still might not be the case. Please share the recording of your CAN raw log as provided before. I will create a tool in GitHub - dronecan/pydronecan: python DroneCAN code generation, interface and utilities to debug this issue using those logs as well.
@sidbh Ok, I see, thank you for the information. I’m attaching some logs with the current configuration. There are logs from 2 different RTK providers (RTK2GO and Polaris).
@AlexPapadimitriou I checked, you still have corrupt packets. This is the PR which adds more debugging to console with regards to packets that failed to parse. You can use this to debug your issue.
Having the same issue here on the same Orin platform.
Also sometimes, just connecting the Cube and the Here4 with nothing else on the CAN bus, and using the corrections from Mission Planner, does not work. No RTCM on the bus.
Seems like not even the string from the GPS is generated (that is required to send to the server for network correction system), as in RTK page in the planner, there’s no data exchanged between the server and the planner at all.
But correction provider works no problem in u-center with serial over can passthrough.
@HeliEngadin please make sure that Mission Planner passthrough is not enabled while trying to enable the normal GPS operation. Mission Planner creates a blocking connection i.e. onboard firmware cannot speak to the GPS module during the passthrough operation. If you need non-blocking connection and various other options for GPS serial passthrough please use DroneCAN GUI Tool
.