Dependent on #2 and #3.

EASY FIX: change the integer '1' to double '1.0'

The spincallback is occurring as fast as it can without sleeping, hundreds of times a second, resulting in too many JointState messages and increasing processor/network load.

This is because the parameter to "createTimer(ros::Duration(1 / hz)" incorrectly evaluates to an integer which will be '0'. The createTimer() parameter is supposed to be a double.

Instead the '1 / hz' should be '1.0 / hz' to make it evaluate to a 'double'. Change the '1' to '1.0'

The driver should gracefully handle:

• PTU being power-cycled
• PTU being unplugged, replugged
• loss/reestablishment of ttyUSB device
• PTU not being finished its startup homing sequence

I'm trying to launch the ptu node but it is returning the following error message:

[ERROR] [1469826506.654626562]: Failed to build tree: child link [ptu_base_link] of joint [base_to_ptu_base] not found

I've been trying to solve that problem but without success. Anyone have an idea about what is that?

Hi all,
When I try to run [roslaunch flir_ptu_driver ptu.launch port:=/dev/ttyS0] I get the next error:

... logging to /home/linus/.ros/log/612d3ff6-68aa-11e5-b769-3cd92b67608a/roslaunch-linus-HP-Compaq-6200-Pro-MT-PC-3145.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://linus-HP-Compaq-6200-Pro-MT-PC:53557/

SUMMARY

PARAMETERS

• /ptu/ptu_driver/port: /dev/ttyS0
• /robot_description: <?xml version="1....
• /rosdistro: indigo
• /rosversion: 1.11.13

NODES
/ptu/
ptu_driver (flir_ptu_driver/ptu_node)
/
robot_state_publisher (robot_state_publisher/state_publisher)

auto-starting new master
process[master]: started with pid [3157]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 612d3ff6-68aa-11e5-b769-3cd92b67608a
process[rosout-1]: started with pid [3170]
started core service [/rosout]
process[robot_state_publisher-2]: started with pid [3187]
process[ptu/ptu_driver-3]: started with pid [3210]
terminate called after throwing an instance of 'serial::SerialException'
what(): SerialException device reports readiness to read but returned no data (device disconnected?) failed.
[ptu/ptu_driver-3] process has died [pid 3210, exit code -6, cmd /opt/ros/indigo/lib/flir_ptu_driver/ptu_node state:=/joint_states __name:=ptu_driver __log:=/home/linus/.ros/log/612d3ff6-68aa-11e5-b769-3cd92b67608a/ptu-ptu_driver-3.log].
log file: /home/linus/.ros/log/612d3ff6-68aa-11e5-b769-3cd92b67608a/ptu-ptu_driver-3*.log
...
I never got this error before, and after my Ubuntu 14.04 was updated on October 1st 2015 this problem started there. I try to manually command flir driver use Arduino IDE serial terminal everything is OK, I can set or query it to certain position. so what is going on with my ROS?

fyi: Ubuntu error confirmation

In driver.cpp, the home() operation is implemented by sending a RESET ' R 'to the ptu, and waiting up to 30 seconds for the reset's response.

Also, the 'R' command does much more than going to the 0,0 pan/tilt, it also controls the calibration, which is probably not what is expected.

I would be better to rename that PTU::reset().

I suggest the the current PTU::home() command should be deprecated and and a new 'PTU::goHome()' defined to avoid confusion.

A better PTU::goHome() command would be implemented with 'pp0 tp0 '. This should only take a maximum of 6.5 seconds at speed 1000, or the speed could be set to 2000 and do the home even faster.

In node.cpp, in Node::spinCallbach(), 4 separate calls are made to get the pan and tilt positions and speeds, but (at lease for the D48E) a single command 'BT' will return the same results on one line. This will help prevent the returned data from getting out of step with the requests, which I have observed or even crashing.

Dear maintainer,

I am interested by a flir_ptu simulation. I found that some discussions occurred partially in that direction
ros-controls/ros_controllers#112 but I could not find a flir ptu simulation.

I dediced to develop one. I created two packages

• flir_ptu_simulation that extends flir_ptu_description on all the gazebo and transmission tags required such as ros_control plugins. In this way controllers can be plugged in, especially the head pointing controllers existing for ros_control probably.
• flir_ptu_controllers that provides a ros_control controller taking JointStates as cmd as in the real driver (does not exist in ros_controllers)

I had to modify flir_ptu_description to include inertia values (estimated ones) in order for gazebo to accept spawning the ptu model, and also added collision elements in the urdf, but that should not affect other users too much.

I got a first working system, but have a few questions before sharing that upstream as a PR

• First of all are you interested ?
• Should the controllers provide exactly the same response as the driver ? for instance I can have the real velocity published in the simulated /joint_states (using a joint_state_controllers) driver and not the max velocity setpoint as in the driver? Or should the provided joint_states look exactly as in real world with constant velocity equal to max velocity setpoint ?

best

Higher end FLIR PTUs (like the D48) are capable of direct TCP/IP control. Would it be possible to expand the functionality of this driver to allow for control via TCP/IP in addition to serial control?

Ideally include demonstration showing LIDAR on PTU, interactive marker control, etc.

EASY FIX: compare to uppercase

The D48E responds to the 'C' query control mode with an uppercase 'P' or 'I', but the driver.cpp compares to lowercase, resulting in an error returning (-1) :
if (buffer[2] == 'p')
return PTU_VELOCITY;
else if (buffer[2] == 'i')
return PTU_POSITION;

This could be fixed like this:
(buffer[2] == 'p' || buffer[2] == 'P' )
(buffer[2] == 'i' || buffer[2] == 'I' )

Probably not in the driver—something which has to be launched separately.

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.

With the current driver, the line:

pub = rospy.Publisher("cmd", JointState)

should be:

pub = rospy.Publisher("ptu/cmd", JointState)

So as not to confuse the new guys :)

Hi,

There is a discrepancy between the rviz/urdf model and current sensor.
If I tell the sensor to move to 0.6 position, the physical sensor moves in the correct direction, but the rviz model moves in the opposity direction. I have issues only with the pan...tilt is fine.

I have a PTU46-70.

Where do I correct this issue, in the URDF, or in the driver.h/cpp?

By the way, that is the default behaviour without me modifying anything on the driver side

Thanks

At present, the node reads parameters from the unit and writes them to the parameter server. The factory defaults appear to be way too aggressive on both speed and acceleration. Attempting to command the claimed maximum speed has the steppers skipping all over the place.

Instead, the top speed and acceleration should be specified in by rosparams and written into the device on startup. Sane, experimentally determined values should be set as the defaults in the driver.

Hi, Thank you for your excellent source code.

I found a missing inertial tag on flir_ptu_description.
There is no inertial tag on ${name}_tilted_link as follow link.

If someone use gazebo, this model won't work correctly.

Hi Folks,

When I run the roslaunch for the ptu.launch, I get the next sequence of errors:

[ERROR] [1423699913.432927534]: Error getting pan-tilt res
[ERROR] [1423699913.632242150]: Error getting pan-tilt res
[ERROR] [1423699913.831551307]: Error getting pan-tilt limit
[ERROR] [1423699914.030850575]: Error getting pan-tilt limit
[ERROR] [1423699914.230154086]: Error getting pan-tilt limit
[ERROR] [1423699914.429461662]: Error getting pan-tilt limit
[ERROR] [1423699914.628747865]: Error getting pan-tilt limit
[ERROR] [1423699914.828042120]: Error getting pan-tilt limit
[ERROR] [1423699915.027332077]: Error getting pan-tilt limit
[ERROR] [1423699915.226578932]: Error getting pan-tilt limit
[ERROR] [1423699915.226634618]: Could not initialize FLIR PTU on /dev/ttyS1

Why does that happen?
Thanks

Can we please get a Kinetic release of this package?

The mount bracket shown in the data sheet is not part of the meshes in this repository and not part of the xacro either.

The setup phase of the unit is completely fire-and-forget, which is terrible. Each setting programmed into the unit should be read back afterward, to verify it.

Current is provided separately (!) in both ptu_action_server.py and ptu_node.py, neither of which look very complicated.

If the driver attempts to launch while the PTU is still completing its startup sequence, it crashes and does not restart. This can happen if the controlling computer and PTU are powered on at the same time.

Adding respawn="true" to the launch file allows the driver to restart successfully, though ideally the driver should wait until the PTU is finished moving so that it doesn't crash at all.