search

kuka-isir / ati_sensor

C++ Libraries to communicate with the ATI NET F/T box.
Other
11 stars 8 forks source link

drivers lags if netft box RDT output rate setting is not 1Hz #2

Closed guihomework closed 8 years ago

guihomework commented 8 years ago

If the netFT box is set via the webinterface to use RDT Output Rate (1 to 7000): 100, and RDT Buffer Size (1 to 40): 1 the current version of the driver, started in ROS, (default loop rate 100Hz) produces data on the topic that lag more than 1 second. With a setting of 1Hz for the RDT Output Rate (probably default in netft box), the output does not seem to lag.

This lag probably comes from an internal buffer, or from a network buffer.

The ROS node should warn the user if the netft setting is not 1Hz. One do not want to overwrite the setting a user might have done in the web interface. A public method could be added to set the Output Rate from the driver.

I will try address these issues and provide a PR when ready and tested.

guihomework commented 8 years ago

tests confirm it is a buffer problem. If the driver reading rate is faster then the rdt output rate, the data shows no visible lag. If the reading rate is the same or below the output rate, the lag is constant, with a value depending on the buffer length (unknown) and on the reading rate.

The current rdt output rate is available in the netftapi2.xml under <comrdtrate> tag

However, the driver has no idea at which rate it will be triggered, so a warning message can only be displayed if the rdt output rate is different than 1Hz.

guihomework commented 8 years ago

I have a warning now in this branch https://github.com/ubi-agni/ati_sensor/tree/rdt_output_rate

but don't have a rtnet setup yet to test it. I guess this very small additional parsing should be ok.

will now try add a method to set the output rate from the driver

guihomework commented 8 years ago

Added the set method using comm.cgi. This is very basic http request, and can be done in rtnet and non-rtnet exactly the same (small chunk size on receive works also in non-rtnet). Tested in non-rtnet.

guihomework commented 8 years ago

Actually, #5 fixes also this issue. This was tricky to find. The sample requested were never 1, but something random. With a RDT output rate higher than read rate, the random number of sample would accumulate faster than one single sample would be read. The next request would actually always read previously requested samples. The whole thing would then lag by the number of sample or udp buffer limit. I will provide a fix PR that removes unnecessary warnings.