Performance issues

[DangerousElectrician]

can_talon_srx is using the CANRecv service way too much and it causes extraordinarily high cpu usage.

[DangerousElectrician]

Look into persistent connections. http://wiki.ros.org/rospy/Overview/Services#Persistent_connections

[DangerousElectrician]

[jacobhuesman]

Is it possible to encapsulate all the functionality into one program?

[DangerousElectrician]

I want to keep ardu_can_bridge separate for communicating with the PDP.

[jacobhuesman]

What is your reasoning behind that?

[DangerousElectrician]

Whole thought process: CanTalonSRX.cpp creates an object for every Talon SRX. I need to support creating multiple Talon SRX objects. Keeping track of what objects have been created is weird. Let's just create a new node for every Talon SRX. The nodes need to get data from the CAN bus. Trying to manage access to a single serial port from multiple running nodes is hard. Try creating a node that sits between the serial port and multiple running nodes. This is ardu_can_bridge.

There were also limitations on how I could get the CAN bus data to CanTalonSRX without having to rewrite how the can bus logic is handled. CANSessionMux.h defined the functions I had to implement to keep compatibility with the wpilib code.

[jacobhuesman]

The simplest way to make the current strategy more efficient might be to convert from a service based structure to a message based one.

Instead of requesting a service from ardu_can_bridge, each time you need data, you could have ardu_can_bridge publish all of the data in a msg and then have each node subscribe to that data. That would limit the interactions between nodes a bit. This could reduce the overhead.

On the making it all one program idea.

What makes keeping track of multiple objects weird in this case? Couldn't you stick them all in an array to keep track of them? When it comes to updating their state you could just iterate through the array and update each object one at a time.

Assuming you can get the objects in the same node. I don't see why it would be impossible to integrate that node with the ardu_can_bridge, although you might have to implement multi-threading to ensure that the serial port is being polled enough.

[DangerousElectrician]

Use case I was designing around: Create can_talon_srx node named "leftwheel" Create another can_talon_srx node named "rightwheel" Control the left wheel of the robot by sending messages to "leftwheel" Control the right wheel of the robot by sending messages to "rightwheel"

Putting the motor control objects into the same node would make telling them apart a bit tricky.

[DangerousElectrician]

ardu_can_bridge now publishes all received messages and can_talon_srx caches them. That help improved things a lot.