CAN acceptance filter

[JamesStewy]

Hi Pavel,

I have a Raspberry Pi plugged into a Babel which is then connected into a CAN network that has a GNSS 2 and a Pixhawk. On the Raspberry Pi I am running a pyuavcan application and I am having a lot of performance issues if there is any non-trivial amount of traffic on the CAN network. Running htop shows that pyuavcan pegs one cpu core at 100%. With #33 now I am also getting a significant delay between the message being sent on the CAN network and it appearing in my pyuavcan application.

Can I suggest the addition of a CAN acceptance filter (or a blacklist) in pyuavcan that stops pyuavcan from processing certain messages and services? That way I can then filter out any high speed messages and save a lot of processing time.

Thanks.

[pavel-kirienko]

Can I suggest the addition of a CAN acceptance filter (or a blacklist) in pyuavcan that stops pyuavcan from processing certain messages and services?

Eh. I guess we can do that, but it would only make sense doing that at the driver layer, immediately after the CAN frame is received from the adapter: https://github.com/UAVCAN/pyuavcan/blob/bfa4241a1a029f48a8683f214ee3087c4aa885be/uavcan/driver/slcan.py#L199

Getting rid of unwanted frames that early will also resolve the latency issue you mentioned. If you'd like to go ahead with that, feel free to submit a pull request.

But it won't solve your problems, really. Raspberry Pi is a calculator on steroids; if you need higher throughput and faster hardware is not an option, migrate to C++ and use libuavcan instead. Libuavcan supports automated acceptance filter configuration (courtesy @ilia-sheremet ) and hardware or software acceptance filters at the driver layer.

[JamesStewy]

I have a minimal working version of what I need for my application over here. You just set rx_blacklist to a list of data type ids to be filtered.

To test it, I again used a GNSS 2 and then filtered out all messages it sends apart from its NodeStatus message. It works and the cpu usage is much lower now (at around 15% according to htop), but it isn't as low as I expected.

But it won't solve your problems, really. Raspberry Pi is a calculator on steroids

I know the Pi isn't the fastest computer but I don't really understand why pyuavcan is much slower than libuavcan on a microcontroller.

[pavel-kirienko]

It works and the cpu usage is much lower now (at around 15% according to htop), but it isn't as low as I expected.

It's profiling time, James. You can use this as an example: https://github.com/Zubax/kucher/blob/83737bae39444ee9ac225d729a2535cc70758521/kucher/main.py#L59-L71

[pavel-kirienko]

Closing because this is already available in PyUAVCAN v1.0, which is being developed in the branch uavcan-v1.0. This feature is not going to be backported to the old implementation unless someone is willing to volunteer.