Subscribing to vendor specific messages

[CyberMerln]

Hi all

I managed to turn libuavcan into Arduino style library for use with the Teensy 3.x mcus.  The teensy driver and examples are taken from the UAVcan site and tum-phoenix (https://github.com/tum-phoenix/drive_teensy_main and https://github.com/tum-phoenix/drive_teensy_libuavcan) and modified appropriately.  I tested the publisher and subscriber sketches using the Sideslip datatype (forgive me if I get the terminology wrong - a lot to uavcan) and it seems to work.  But now I am trying to use a vendor specific data type for IMU data.  I converted it .hpp using the dsdl compiler and am able to publish messages, sample data below:

LEN: 8 EXT: 1 REMOTE: 0 TS: 14979 ID: 269716326 Buffer: 52 23 A2 5D 4B 51 0 93
  LEN: 8 EXT: 1 REMOTE: 0 TS: 15114 ID: 269716326 Buffer: 0 0 B0 1D B0 9D 8D 33
  LEN: 8 EXT: 1 REMOTE: 0 TS: 23168 ID: 269716326 Buffer: 91 93 9F 7D 4B 51 0 94
  LEN: 8 EXT: 1 REMOTE: 0 TS: 23305 ID: 269716326 Buffer: 0 0 8D 1C 8D 9C 0 34
  LEN: 8 EXT: 1 REMOTE: 0 TS: 23443 ID: 269716326 Buffer: 0 1F 25 AE 27 8D 1C 14
  LEN: 7 EXT: 1 REMOTE: 0 TS: 23581 ID: 269716326 Buffer: A0 5D 0 C4 40 BC 74
  LEN: 8 EXT: 1 REMOTE: 0 TS: 32005 ID: 269716326 Buffer: 25 B0 24 A0 4B 51 0 95
  LEN: 8 EXT: 1 REMOTE: 0 TS: 32143 ID: 269716326 Buffer: 0 0 B0 9D D4 1A 0 35
  LEN: 8 EXT: 1 REMOTE: 0 TS: 41857 ID: 269716326 Buffer: 11 F6 A2 C6 4B 51 0 96

 

Unfortunately I am not able to see the data using the subscriber sketch that worked with the sideslip datatype.  I've read what I could on vendor specific messages but could not figure out why it should not work.  I did post a issue on the tum-phoenix GitHub page: https://github.com/tum-phoenix/drive_teensy_main/issues/3  but figured I post here to see if anyone has any idea.  I can post the code and datatype if you think that would help.

Thanks

Mike

[CyberMerln]

To make life easier here are the message files and the sketch (c++) I am using.

Respectfully

Mike

[Pavel Kirienko]

Hi Mike,

In general, the following should be helpful: https://uavcan.org/Implementations/Libuavcan/Tutorials/1._Library_build_configuration/#debugging-and-troubleshooting

The frame sequence you posted seems to contain three transfers, of which only one is correct. The correct one is shown below:

  LEN: 8 EXT: 1 REMOTE: 0 TS: 23168 ID: 269716326 Buffer: 91 93 9F 7D 4B 51 0 94 - start of transfer

  LEN: 8 EXT: 1 REMOTE: 0 TS: 23305 ID: 269716326 Buffer: 0 0 8D 1C 8D 9C 0 34   - toggle 1

  LEN: 8 EXT: 1 REMOTE: 0 TS: 23443 ID: 269716326 Buffer: 0 1F 25 AE 27 8D 1C 14 - toggle 0

  LEN: 7 EXT: 1 REMOTE: 0 TS: 23581 ID: 269716326 Buffer: A0 5D 0 C4 40 BC 74    - end of transfer, toggle 1

Its CRC is 0x9391 (the first two bytes),

and the payload is 9F 7D 4B 51 0 0 0 8D 1C 8D 9C 0 0 1F 25 AE 27 8D 1C A0 5D 0 C4 40 BC (25 bytes, which fits your data type definition);

where:

    9F 7D 4B 51 00 00 00 - timestamp (uptime 23 minutes?)

    8D 1C 8D 9C 00 00 - gyro (the last element is zero? suspicious)

    1F 25 AE 27 8D 1C - accel

    A0 5D 00 C4 40 BC - angle

The transfer looks correct, at least as far as its format goes. If it could not be decoded successfully, the data type definition on the source and the destination may be different.

You need to ensure that you are using EXACTLY the same definitions.

If the data fields are named differently or rearranged things will not work.

Things look bad with the other transfers - they only have the first two frames, the continuation frames are missing:

  LEN: 8 EXT: 1 REMOTE: 0 TS: 14979 ID: 269716326 Buffer: 52 23 A2 5D 4B 51 0 93 - start

  LEN: 8 EXT: 1 REMOTE: 0 TS: 15114 ID: 269716326 Buffer: 0 0 B0 1D B0 9D 8D 33  - toggle 1, more frames expected, but where are they?

  LEN: 8 EXT: 1 REMOTE: 0 TS: 32005 ID: 269716326 Buffer: 25 B0 24 A0 4B 51 0 95 - start

  LEN: 8 EXT: 1 REMOTE: 0 TS: 32143 ID: 269716326 Buffer: 0 0 B0 9D D4 1A 0 35   - same thing, missing frames

The CAN driver you're using seems to be broken.

This is not related to your question, but it's important: the implementation of libstdc throw stubs __throw_bad_alloc, __throw_length_error, and __throw_bad_function_call is incorrect - they must never return, otherwise bad things may happen.

Hope this helps!

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+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/f405781e-2da3-478f-bc18-94ad10514dd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pavel Kirienko]

By the way, consider using UAVCAN GUI Tool - it is quite good at catching these kinds of errors: https://uavcan.org/GUI_Tool/

Pavel.

[CyberMerln]

Hi Pavel

Thanks for getting back to me so quickly, especially with the detailed analysis of the CAN packets.  Been working through the UAVcan guides but quite a bit there.  Yes you are right the build configuration and trouble shooting page was a great help.  Was trying to turn DEBUG on but ran into a bit of trouble with toString.  On lot of compiler errors were being thrown about toString not members of xxx, where xxx is in the format of xxx.toString().c_str() or xxx -> toString().c_str() etc.  Tried turning on exceptions but with the Arduino IDE and the c++ compiler used was giving me a bit of a problem.  Have to try and sort that one out.

The last point about the stubs will make sure that point is taken care of.

Things look bad with the other transfers - they only have the first two frames, the continuation frames are missing:  - Not sure why the CAN driver is working will have to dig into that a bit more.  Think I will switch over to sideslip test again.  At least I can see output vs what is being sent.  That may be a function of the sniffer I was using. I do know that the driver is receiving messages from the publisher so maybe I will print out those frames as a check.

You need to ensure that you are using EXACTLY the same definitions. - pretty sure they are the same but will do a double check, just in case.

I saw the Python GUI but was sure how it worked with using two mcu's.  Guess I will have to dig into that as well.

Well, have a lot to work on over the next couple of days.

Thanks for all your help. Been working on this for a while and feel it's almost there.

respectfully,

Mike

[CyberMerln]

Hi Pavel

Figured I would give you an quick update.  I updated the Flexcan library that I was with UAVcan.  Made a couple minor changes to compatibility and worked like I charm  Was sending and reading the messages with the publish and subscribe sketches.  So you were right - it was the driver :)

Thanks for your help

Mike 

[George Small]

Hi Mike,

Thanks for posting, I've been exploring paths to get into UAVCAN and appreciate the work you put into developing and posting your library!  This could make UAVCAN very accessible.

I have a Teensy 3.2 and a 3.6 available for test, along with some known good 3.3V SN65HVD230 based CAN adapter boards.  I'm attempting to try your library out on both Linux and Windows.  I plan to document my findings so that others can duplicate if desired.  I've managed to download and compile a couple of examples.  I found a few Windows related errors in Linux (backslash and capitalization related) that I had to fix to get the Linux side to compile but no big deal..I can share if interested.

I'm wondering what you would recommend for me to test out the function of the examples.  I have a working SLCAN based adapter I've been using for other testing.  Is there a way I can test functionality with the SLCAN adapter plus UAVCAN GUI?  Any advice would be much appreciated.

Best Regards,

George

[CyberMerln]

I've been exploring paths to get into UAVCAN and appreciate the work you put into developing and posting your library!  This could make UAVCAN very accessible.

Thanks for the compliment.  Could not of done it with the help of Pavel and a couple of others on the Teensy forum. 

 

I plan to document my findings so that others can duplicate if desired.  I've managed to download and compile a couple of examples.  I found a few Windows related errors in Linux (backslash and capitalization related) that I had to fix to get the Linux side to compile but no big deal..I can share if interested.

Sharing would be great.  Guess you could do that here or even on the Teensy forum.

I have a working SLCAN based adapter I've been using for other testing.  Is there a way I can test functionality with the SLCAN adapter plus UAVCAN GUI?  Any advice would be much appreciated.

Don't know much about SLCAN yet.  Working on that over the next couple of days.  I just ordered one Tindie and was going to start playing around with the GUI once on get it.  Not sure when though.  Maybe this week. As for testing functionality with the GUI can't help you there yet. :)  

As for testing out the capabilities I actually started with using a BNO055 and using the custom message for sending IMU orientation data.  Next I want to attach a GPS to another Teensy and use timers and filters for the data.  This should show what you can expect.  This is my approach to testing.   Not sure what else I can recommend.  

Regards

Mike