Create CanBusPeak device

roboticslab-uc3m / yarp-devices

A place for YARP devices

https://robots.uc3m.es/yarp-devices/

9 stars 7 forks source link

Create CanBusPeak device #190

Closed PeterBowman closed 6 years ago

PeterBowman commented 6 years ago

Solves https://github.com/roboticslab-uc3m/yarp-devices/issues/146. This PR has been developed in parallel to https://github.com/roboticslab-uc3m/yarp-devices/pull/158 and integrates all solutions adopted outside the CAN device itself (support for message buffers and acceptance filters, new policies, etc.). Its main goal is the creation of another implementation of yarp::dev::ICanBus that supports our new Peak-CAN boards.

Also, basic directory layout is prepared for the upcoming CanBusSocket device.

coveralls commented 6 years ago

Coverage remained the same at ?% when pulling f83dc20e4b62eba4aa426288a8d55681c9ea2a46 on fix-146-peak into 1feefbcd820b4bd626c8c1bdeaeb0e7da9afd8b3 on develop.

PeterBowman commented 6 years ago

Tested on TEO and working, please review (:wink: :wink: @jgvictores). Only two issues which I don't consider as blocking for this PR:

Initialization times have increased. It takes more time to perform all steps in CanBusControlboard::open() than before #158.
If no CAN nodes are present (but configured via .ini), the output is bloated with read errors on close. I need to review the full termination sequence, i.e. whether the CAN device is closed before entering CanBusControlboard::close().

PeterBowman commented 6 years ago

Ok to merge?

Yeah. I'll be working on the increased init times with the current HiCO.CAN setup in the next days. Termination issues shouldn't require real hardware for being debugged (CanBusFake + FakeJoint).

PeterBowman commented 5 years ago

Follow-ups:

https://github.com/roboticslab-uc3m/yarp-devices/issues/191 (transmit delays)
https://github.com/roboticslab-uc3m/yarp-devices/commit/9e7c30923bc399dcf282aa1501ef3aaf6f9cd8df (forgot to properly initialize a C structure)