How to structure CAN message for Simulink+Arduino to Tinymovr communication?

[Gnorv]

Intention

I want to build Simulink Code to be run on Arduino Hardware. The Arduino is equipped with a CAN shield, which is used to connect it to the Tinymovr. I have run the Arduino examples from the website to confirm the connection is working.

The Simulink code should enable the Arduino to receive position information from the Tinymovr, use it in a PID, and send back a velocity command to the Tinymovr.

Question

I am wondering how I should structure the message for the velocity command for the Tinymovr to understand it. In the screenshot below are the options that I have in Simulink.

I am aware that I need to know the CAN ID of the tinymovr, which I can set with the Tinymovr Studio. I am also aware that I somehow need to put the information that I am sending the velocity setpoint. I am just not sure if I need to combine the CAN ID and the message ID (for the velocity setpoint it would be 23, for the position estimation 53) into the extended 29-bit CAN Identifier, or if I should add the message ID as a signal in the CAN Pack block in the screenshot.

Could someone help me with how I should structure my CAN message?

I am looking for information similar to the following image, about how many bits of which part of the message I should put where.

This image is taken from the Solo Pico UART & USB Manual, page 14.

Additional Information

From the Simulink documentation about the CAN pack block it seems CAN ID of the Tinymovr and message ID should be combined and put into the CAN Identifier field.

[yconst]

Please take a look here: https://github.com/tinymovr/Tinymovr/blob/76b6051769eba918b59c8f8aa996a7ad71215ee3/studio/Python/tinymovr/channel.py#L102

These two functions pack and unpack node IDs, endpoint IDs and a hash value corresponding to the protocol version to and from CAN arbitration IDs that can be used in your messages. You will need to structure your arbitration IDs like this. For the protocol version, you can use zeros as a starting point, it is accepted.

With respect to the Data Field, it is always the first n bytes, and the size n is determined by the data type. For instance, an uint8 has a size of 1 byte. An IEEE754 float has a size of 4 bytes.

For messages that you send to retrieve data, the RTR bit needs to be set, and the Data Field should be empty (DLC==0)

[Gnorv]

Sending CAN messages Arduino → Tinymovr

Thank you for the reply. By monitoring all CAN messages in the network with Cangaroo, as suggested by the Getting Started of CANable, and the CANine adapter, I was able to reverse engineer the structure of the messages into my simulink code.

I can now send commands to the Tinymovr. The screenshot below shows transmitting the request for the position estimate as a remote frame. In a similar way I can put the Tinymovr in to velocity control mode, and send velocity setpoints.

For messages that you send to retrieve data, the RTR bit needs to be set, and the Data Field should be empty (DLC==0)

I guess ticking the Remote Frame checkbox enables the RTR bit, as you mentioned.

Receiving CAN messages Arduino ← Tinymovr

Now I am facing the next issue, that is receiving back position information. I can send the position feedback request, and I also do see the response in Cangaroo. However, the Arduino does not seem to be able to read the message in the current configuration. The Arduino is running at 0,003 s sampling time, at which it also receives and sends CAN messages. The CAN baud rate is at 1000 kbit/s, but I also tried setting it to 125 kbit/s (on both the Tinymovr and the Arduino).

The result is always the same: I can send messages from Arduino to Tinymovr, but the CAN receive block never outputs any data on any of its 3 ports, even while seeing the response in Cangaroo.

EDIT: Check my reply below to see how I got the receiving of CAN messages Arduino ← Tinymovr working.

Side note

When I change the CAN baud rate of the Tinymovr to 125 kbit/s (or anythong other than 1000 kbit/s), then the Tinymovr Studio does not automatically detect the Tinymovr board anymore. I launched the Studio and CLI as descibed in the documentation with the respective commands tinymovr and tinymovr-cli. Is there maybe an option to launch the Studio with, telling it a specific baud rate to use?

[yconst]

As the Tinymovr periodically sends a heartbeat frame, it is possible that the limited buffers of the MCP2515 capture the heartbeat and present this when querying the input buffer. I'd suggest looking at the Arduino library and especially this code:
https://github.com/tinymovr/Tinymovr-arduino/blob/e97cfe23d111d30b3a51d2031c3c7485a8cff26a/examples/arduino_mkr_wifi_1010/arduino_mkr_wifi_1010.ino#L108

Where the correct filter to throw away the heartbeat message is shown. Apart from that I cannot see any other reason why the message is not received, especially given that the cangaroo receives it.

Regarding available command line options, including bitrate configuration, please check tinymovr --help

[Gnorv]

Thank you, filtering out the heartbeat message did the trick. I can now send and receive messages between the Arduino and Tinymovr using Simulink. Below I will document my steps regarding the message receiving from Tinymovr, in case someone else will want to follow them. The sending to Tinymovr I already documented above.

Following the reasoning outlined here, I tried setting Acceptance Mask and Acceptance Filters to only allow the messages I want to receive, meaning the position estimate from the Tinymovr. Therefore the hearbeat frame would not flood the input buffer of the Arduino, as mentioned by @yconst. Below a screenshot of the Hardware Configuration in Simulink to accept only position estimate messages from Tinymovr.

Acceptance Mask as 255, as that says only the 8 bits of the received CAN identifier that contain the message ID are relevant (see picture below). Acceptance Filter 53 corresponds to the message ID of encoder.position_estimate message in the API reference. Messages with 43 (comms.can.id) are also accepted, but that is not relevant for receving the position estimate.