Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add native CAN bus support on Linux #39

Merged
merged 1 commit into from Jul 19, 2019

Conversation

@nitrousnrg
Copy link
Contributor

commented Jul 12, 2019

Working towards #37 , a new tab in the connection page allows to view CAN interfaces
available (e.g. can0, can1, etc), and scan the bus to discover all
connected VESCs. Once discovered, the user can choose a VESC in
the network and connect to it.

image

Its been many years since I coded in C++ and Qt so there might be some odd coding here.

Known issues:
mcconf is properly read and written, and realtime data works, but currently firmware upload fails with a timeout. I am working on it but I think I would like some early feedback before I spend more time on it.

Add native CAN bus support on Linux
A new tab in the connection page allows to view CAN interfaces
available (e.g. can0, can1, etc), and scan the bus to discover all
connected VESCs. Once discovered, the user can choose a VESC in
the network and connect to it.

Signed-off-by: Marcos Chaparro <mchaparro@powerdesigns.ca>
@vedderb

This comment has been minimized.

Copy link
Owner

commented Jul 17, 2019

Very nice addition! Unfortunately I don't have any CAN hardware to test it, but the code looks good after a quick look. The only comment I have is that pageconnection.ui should have the first tab selected by default, which is easy to miss. The UI editor will select the tab by default that was open when the ui file was saved.

@vedderb

This comment has been minimized.

Copy link
Owner

commented Jul 17, 2019

Is there any CAN to USB dongle that I can order on ebay or so btw? I really would like to test this and have a look at the firmware upload issue.

@nitrousnrg

This comment has been minimized.

Copy link
Contributor Author

commented Jul 17, 2019

Yeah I missed the default tab issue.

You can order one of these adapters:
https://canable.io/
Many others will work as well, they all come with a firmware for stm32f0 that can be set as a canbus interface on linux. Slcand and candlelight are the most prominent firmwares for this.
There is a qt project called cangaroo in github that seems to provide support for these dongles in windows platform by implementing the low level driver for the candlelight firmware.
Btw you can see the traffic in wireshark as well.

@vedderb vedderb merged commit 284bc91 into vedderb:master Jul 19, 2019

@vedderb

This comment has been minimized.

Copy link
Owner

commented Jul 19, 2019

Just ordered one. When it comes and I'm home again I will have a look at the fw update problem, hopefully it is easy to fix.

@vedderb

This comment has been minimized.

Copy link
Owner

commented Jul 19, 2019

I had a quick look and made some fixes (that maybe broke something, especially the non-blocking CAN scan), but I couldn't see any obvious reason why firmware updates shouldn't work. Does reading and writing configurations work (as they also cause large packets)?

@nitrousnrg

This comment has been minimized.

Copy link
Contributor Author

commented Jul 20, 2019

Ah, I wasn't expecting such an early merge, thanks!
Yes, mcconf read and write worked well, so did realtime data. I found that high speed data sampling doesn't work either and I'm starting to suspect that the usb-canbus converter is getting overflows, its an unbuffered device or has a short buffer.
My usb converter clone for some is not working with candlelight firmware but I'm waiting for proper boards to arrive to test it. I've read that candlelight fw has higher performance than slcand fw.
I hope we don't need a new thread buffering this can interface.

@vedderb

This comment has been minimized.

Copy link
Owner

commented Jul 20, 2019

I went through the code a bit more carefully, and found a few problems:

  • The length byte was not removed correctly for packets between 6 and 255 bytes.
  • Single frame packets were probably split up in many cases as the <6 check included the length and crc.
  • Long packets had the second byte set to 2, so that no reply would be sent back.

I think the last problem would cause the FW upload to fail, as the ack would not be sent back that way.

Can you give my latest commit a try? I couldn't test it as I don't have a can adapter yet.

@nitrousnrg

This comment has been minimized.

Copy link
Contributor Author

commented Jul 20, 2019

Oh, thanks for taking a look. I think I was going to figure out the first 2 issues, but the third one involves a part of the protocol that I didn't understood.

I gave your patch a quick test and it's not successfully discovering any node in the canbus so I can't connect, but don't worry I'll take a closer look and fix it soon.

@vedderb

This comment has been minimized.

Copy link
Owner

commented Jul 20, 2019

The last part is a bit tricky, and controls how CAN packets are forwarded between VESCs. If the send byte is 0, the packet is processed on the VESC and a possible response is sent back over CAN, with send set to 1. If send is 1 the packet is not processed, but forwarded to the last communication interface. This means that when CAN forwarding is used, packets are send from e.g. USB->CAN->Process->CAN->USB.

Option 2 for send is something I added recently. It is the same as 0 but the reply (if any) is discarded. This is for commands that are sent to multiple VESCs simultaneously, so that not all VESCs send replies at the same time.

I just made a few more fixes, and figured out why the scanning wouldn't work. Can you give it a try again?

@nitrousnrg

This comment has been minimized.

Copy link
Contributor Author

commented Jul 20, 2019

I tried and scanning now works. Upon connect it says

Could not read firmware version. Make sure that the selected port really belongs to the VESC.

I see traffic from the board to the pc. It seems to send the FW version payload, then a large payload, likely mcconf, then fw version again and 2 large payloads, likely mcconf and appconf.

I can take a deeper look on monday to debug this

@nitrousnrg

This comment has been minimized.

Copy link
Contributor Author

commented Jul 20, 2019

Its a CRC error.

Just defining these 4 variables (len hi, len lo, crc hi, crc lo) as unsigned char instead of just char gets the crc checker back to work

char len_high = payload[2];

Firmware update not working yet, but fast data sampling works nicely, glad to see it wasn't a converter issue.

@nitrousnrg

This comment has been minimized.

Copy link
Contributor Author

commented Jul 20, 2019

I found the error, when vesc tool decodes a short canbus packet it doesn't add start, stop and crc. Will code it when I get back to the lab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.