Hello all,
I am using a RPI 3b+ with a MIKROE CAN to SPI 3.3 volt click board. I am attempting to read RAWIMU through the can bus port on the pixhawk. I am using socket can and was able to test my hardware setup and am able to send an receive messages.
Here is my problem, when I connect my pixhawk to the bus I cant read any CAN messages from the pixhawk. I have setup all the necessary parameters in mission planner. Do I have to send a message before I can start reading?
You need to make sure that the APM is actually publishing the data you are looking for. Consider using a conventional USB-CAN adapter with the GUI tool to test that.
Thank you for the reply Pavel,
I meant to ask this question before…
So is it possible to use uavcan.equipment.ahrs.RawIMU to read raw imu data from the can bus port of the pixhawk in arduplane?
I have a USB-CAN adapter too. I will try that next
I plugged in a USB-CAN adapter and clicked read. I am seeing traffic! The problem is I am only seeing one node id: 1001550A go by at about one Hz. Should I be seeing more then one node id if other sensors are publishing to the bus?
This is not a node-ID. This is a NodeStatus message from a node whose node-ID is 10 (0x0A).
Yes. Apparently, the autopilot is not publishing the data you need. I suggest you read the user manual or ask the maintainers why the data you are after is not being published and how to enable it.
Thanks again,
This helps a lot. Looks like I have my work cut out for me. I was thinking the pixhawk was already doing this and the dsdl definitions were directly usable.
Dose the NodeStatus message have anything to do with the UAVCAN DSDL messages?
The software is not publishing the data you are looking for.
(there is a terminology issue: when you say “Pixhawk”, you are referring to the hardware, which is not really what you should be talking about; instead, you should be referring to the software stack running on that hardware, such as ArduPilot or PX4; the same stack can be used with other hardware platforms but its feature set is largely invariant to the type of the underlying hardware).
Of course. It’s a standard message type defined by the Specification. It is available in the stable version of UAVCAN as well, but under a different name uavcan.node.Heartbeat.1.0.