Open jbcolme opened 8 years ago
Hmm, that sounds like it'd be really bad if it was the case, but I think there's something else going on here. The while(ros::ok())
in the main function is intended to be a connection-retry loop— upon successful connection, the driver sits in the ros::spin()
function and operates primarily via the timer callback.
Can you describe more about your setup and how things were failing?
Hi @mikepurvis , I'm a colleague of @jbcolme The issue is the following: after our PTU46 is connected to the serial port (but is the same with USB), it starts sending the following message: "independent (default) speed control mode" This cause the node to crash, as it is always expecting a number followed by a star * character.
The crash is at line 54, where the driver tries to execute a lexical cast on the trimmed response from the PTU.
Also during the initialization phase, sometimes it fires some errors because there are strings in the PTU response rather than just a number and a star.
The issue should be easily solvable if the software catched the lexical cast and tried to manage the custom strings...but when I try just to ignore the exception somehow the previous pos values are not kept and I don't know how to handle this.
If you could make a hotfix it would be really appreciated.
Any update on the issue?
I cannot use it. It keeps crashing. I went through the code, and at the main function of the node, found that for every spin (in the while(ros::ok()) loop) you define a new ptu and connect to it. I put this outside the loop and everything worked.