Mutex on code - Info

[metropt]

Hello,

Can you help me understand what these 3 lines does?

// Notify the ROS thread that a message response (ack/nack) has arrived.
boost::lock_guard<boost::mutex> lock(last_response_mutex_);
last_response_ = msg;
last_response_available_.notify_one();

[mikepurvis]

The basic idea of the driver is that the ROS thread is able to transmit serial commands to the motor driver, while a secondary thread receives data from the device. You can see these two threads getting setup in the main:

https://github.com/g/roboteq/blob/e8fa32d9f5b2d037cd25f15d738807dc664111b3/roboteq_driver/src/driver.cpp#L64

All that the Controller::spinOnce function does is call the blocking read method continuously. Unfortunately, it's not totally clear what the ack notifier does, as the other half of it was never written. But the idea was that this logic could safely pass responses from the reading thread back to the ROS thread, to enable the more transactional approach needed for sending configuration parameters down to the device, for example. Basically the ROS thread would send a message, then would block until the last_response_available_, then process whatever was in last_response_. This would occur via the sendAck or sendAckVerify stream entites.

Ultimately this wasn't implemented because for Grizzly we just bake all the configuration into the MBS script that is downloaded on startup. The script itself is checksummed, which obviates the need for a lot of messaging back and forth. However, if there was an ambition to have the configuration settable using rosparams, this could be a route to implementing it.

[metropt]

So, it takes care of data to be written into the serial port and other ros callbacks

ros::AsyncSpinner spinner(1);
spinner.start();

while this take care of incoming bytes?

while (ros::ok()) {
   controller.spinOnce();
}

Do you have any example on how it could be done?

Basically the ROS thread would send a message, then would block until the last_responseavailable, then process whatever was in lastresponse. This would occur via the sendAck or sendAckVerify stream entites. take care of incoming bytes?