UAVCAN Receive rate problem on Pixhawk

[Duncan Greer]

This is a cross post from px4users - apologies in advance if this is not allowed.

We've implemented some custom UAVCan messages, but have an issue whereby it appears the messages are only received (or at least processed) at 1Hz, whereas the data is coming on on the bus at 10Hz (verified by 3rd party CANBus dongle).

I've modelled our receive sensor bridge on the UavcanBarometerBridge.

I'd appreciate any pointers as to where the problem may lie or how to best go about debugging.

Thanks,

Duncan

[Pavel Kirienko]

Hi Duncan,

Cross-posting is totally fine.

You should read this section on performance counters, perhaps it might help: http://uavcan.org/Implementations/Libuavcan/Tutorials/1._Library_build_configuration/#perfcounters. The stuff related to the transfer error counters is also relevant to your case.

Also, it might help to see a short traffic dump from your bus, perhaps the frames are malformed?

Another possible (but unlikely) reason is that there is not enough computational power available to the library, so it can't process all CAN frames in time.

Pavel.

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/6d4639a2-3362-4418-8424-70577610e6ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Duncan Greer]

Thanks for the tips Pavel.

I've checked CPU load and that doesn't seem to be a problem (uavcan ~1.5% with Idle task > ~50%)

I'll check out the performance counters today.

Duncan

On Thursday, June 22, 2017 at 4:48:23 AM UTC+10, Pavel Kirienko wrote:

Hi Duncan,

Cross-posting is totally fine.

You should read this section on performance counters, perhaps it might help: http://uavcan.org/Implementations/Libuavcan/Tutorials/1._Library_build_configuration/#perfcounters. The stuff related to the transfer error counters is also relevant to your case.

Also, it might help to see a short traffic dump from your bus, perhaps the frames are malformed?

Another possible (but unlikely) reason is that there is not enough computational power available to the library, so it can't process all CAN frames in time.

Pavel.

On Wed, Jun 21, 2017 at 2:27 AM, Duncan Greer <dunca...@gmail.com> wrote:

This is a cross post from px4users - apologies in advance if this is not allowed.

We've implemented some custom UAVCan messages, but have an issue whereby it appears the messages are only received (or at least processed) at 1Hz, whereas the data is coming on on the bus at 10Hz (verified by 3rd party CANBus dongle).

I've modelled our receive sensor bridge on the UavcanBarometerBridge.

I'd appreciate any pointers as to where the problem may lie or how to best go about debugging.

Thanks,

Duncan

--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.

To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+un...@googlegroups.com.

[Duncan Greer]

I think we've traced the problem back to the Transfer ID. Our remote nodes use a static Transfer ID UAVCan receiver seems to be rejecting the repeated messages. I yet to dive into that part of the code.. based on the guidance in the protocol definition I think we need to increment the Transfer ID - is that correct?

Duncan

[Pavel Kirienko]

Hi Duncan,

 

Yes, static transfer ID values are not allowed. This is because CAN bus has some design deficiencies that may lead to the same frame being retransmitted multiple times even if it was delivered correctly the first time. The transfer ID field allows the receiving nodes to detect this condition and discard the repeated data. Additionally, the transfer ID feature enables automatic seamless transition between redundant interfaces at the protocol level, so the application doesn't need to know (unless it is required) if the protocol had to switch to a backup interface if the primary one has failed. In short, the transfer ID field is very important for correct functioning of UAVCAN.

 

-- 

Pavel Kirienko

+7 926 253 2081

Zubax Robotics OÜ

 

 

 

24.06.2017, 00:48, "Duncan Greer" <dunca...@gmail.com>:

I think we've traced the problem back to the Transfer ID. Our remote nodes use a static Transfer ID UAVCan receiver seems to be rejecting the repeated messages. I yet to dive into that part of the code.. based on the guidance in the protocol definition I think we need to increment the Transfer ID - is that correct?

Duncan
 

--

You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+un...@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/b8d2ee98-d234-4044-9674-a3d652779180%40googlegroups.com.