ardupilot/libraries/AP_CANManager
Tom Pittenger 2bbd7d8d91 AP_CANManager: set _driver_type_cache for *all* ifaces 2023-04-17 11:52:52 +10:00
..
AP_CANDriver.cpp AP_CANManager: promote KDECAN to a first-class library 2023-04-17 11:52:52 +10:00
AP_CANDriver.h AP_CANManager: remove unneccesary includes of AP_Vehicle_Type.h 2022-11-02 18:35:48 +11:00
AP_CANIfaceParams.cpp AP_CANManager: correct parameter metadata error 2022-03-14 08:18:13 +11:00
AP_CANManager.cpp AP_CANManager: set _driver_type_cache for *all* ifaces 2023-04-17 11:52:52 +10:00
AP_CANManager.h AP_CANManager: promote KDECAN to a first-class library 2023-04-17 11:52:52 +10:00
AP_CANManager_config.h AP_CANManager: add and use option to compile SLCAN support out of code 2023-03-15 19:08:09 +11:00
AP_CANSensor.cpp AP_CANSensor: create a separate register driver method 2021-07-23 16:01:29 +10:00
AP_CANSensor.h AP_CANSensor: add get_driver_type() accessor 2023-04-17 11:52:52 +10:00
AP_CANTester.cpp AP_CANManager: remove KDECAN from CANTester 2023-04-17 11:52:52 +10:00
AP_CANTester.h AP_CANManager: remove KDECAN from CANTester 2023-04-17 11:52:52 +10:00
AP_SLCANIface.cpp AP_CANManager: add and use a "bool read(c)" method to AP_HAL 2023-03-22 17:59:11 +11:00
AP_SLCANIface.h AP_CANManager: add and use option to compile SLCAN support out of code 2023-03-15 19:08:09 +11:00
README.md AP_CANManager: remove KDECAN from CANTester 2023-04-17 11:52:52 +10:00

README.md

Testing And Debugging

In case unavailability of all the CAN modules that we support, I have created a CAN Driver called CANTester. Currently there are following modes inside CANTester:

1: TEST_LOOPBACK

This test verifies if the low level ifaces are functioning properly. To do that messages are sent so as to ensure TX buffers are filled to the max, and also read the data of the bus. Sequence of incoming data is tested, and also that no transmitted packet was dropped during transmit.

2: TEST_BUSOFF_RECOVERY

This test is only applicable to boards with H7 chip, where the bus off needs to be handled manually. This test is implemented to check if Bus off recovery is handled and recovered properly. Busoff error can be generated by simply shorting the CANH and CANL.

3: TEST_UAVCAN_DNA

This test simply creates a uavcan node allocation client and tries to get node allocated, the allocated node needs to match the requested node id for success. This tests AP_UAVCAN and underlying DNA library.

4: TEST_TOSHIBA_CAN

This test simply emulates a ToshibaCan ESC on a bus and handles the data sent by Toshiba CAN driver, and and also responds with ESC telemetry.

A lot more tests will be needing to be added overtime to ensure robustness and maintainability of CAN Ecosystem.

Testing under SITL

https://github.com/linux-can/can-utils contains a nice set of utility to do CAN related testings on Linux system. I used Ubuntu for this development, for Ubuntu systems you can simply download this tool using sudo apt-get install can-utils

Following are the common commands that can be used while testing or developing:

  • Create Virtual CAN Interface:
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
sudo ip link add dev vcan1 type vcan
sudo ip link set up vcan1
  • Route one CANSocket to another
sudo modprobe can-gw
sudo cangw -A -s vcan0 -d vcan1 -e
sudo cangw -A -s vcan1 -d vcan0 -e
  • Delete routes
sudo cangw -D -s vcan0 -d vcan1 -e
sudo cangw -D -s vcan1 -d vcan0 -e
  • Route SLCAN to VCAN, this allows connecting CAN devices to SITL run via CAN Adapter like the one running in Ardupilot itself.
sudo modprobe slcan
sudo slcan_attach -f -s8 -o /dev/ttyACM0
sudo slcand ttyACM0 slcan0
sudo ifconfig slcan0 up
sudo cangw -A -s vcan0 -d slcan0 -e
sudo cangw -A -s slcan0 -d vcan0 -e
  • Dump can messages:
sudo candump vcan0