dxl_reacher sensor_dt time exceeded about senseact HOT 14 CLOSED

Hi @csherstan, what's your system specs? I had a lot of the hiccup warning when running experiments on a standard laptop. However, nearly no hiccups when using more powerful machine with these specs - 6 x 3.5 GHz AMD FX 6300 Cores and 2GB Nvidia GeForce 950 GPU

from senseact.

I'm using my laptop at school. It's a few years old now, but was high end when we got it.
i7-4800MQ @ 2.70 GHz x 4. NVIDIA Quadro K1100M. 16 GB RAM

from senseact.

Is it reasonable to bump up my timeouts? I set gripper_dt=0.04 in dxl_reacher.py:24 and now it seems happy.

from senseact.

I also wonder if increasing the cycle time (dt) would effect the reproduciblity of the learning curve?

from senseact.

@csherstan Your specs seem fine. The processor speed and number of cores in the machine had a significant effect on hiccups. You can always bump up the gripper_dt and agent_dt to whatever works best for you. For example, a 40ms gripper_dt and 80ms agent_dt should still achieve good performance.
@danielsnider That's correct. You'll end up getting a learning curve that's different from the one we reported in the paper. A particular combination of agent_dt, gripper_dt and hyper-parameters would get you the best performance. It might be similar in performance (we do reward scaling based on agent_dt to make returns comparable across multiple action cycle times). However, that would not affect the repeatability of your learning curves. If you use the same random states for initialization, choose a gripper_dt that doesn't have any (or very few) hiccups and use the default hyper-parameters in the examples, you should be able to get the extremely similar learning curves.

from senseact.

Not sure how often you are seeing the warnings. As far as I know if the warning only happens during a learning update then the effect should be minimal. It only becomes a problem if the warning happens more often than that (eg, on every timestep).

from senseact.

Did you see similar hiccups nearly every read-write cycle time as well, @danielsnider, with gripper_dt=0.01?

from senseact.

@armahmood, Yes I do, with gripper_dt=0.01. I'm just on my laptop[1]. I find with gripper_dt=0.025 I only get warnings once in a while, like 1 in 100 episodes.

[1] my laptop specs:
Processor: 8th Generation Intel® Core™ i7-8650U Processor with vPro (1.90Ghz, up to 4.20Ghz with Turbo Boost, 8MB Cache)
Memory: 16 GB LPDDR3 2133Mhz onboard
Graphic Card: Integrated Intel UHD Graphics 620

from senseact.

So this is odd. I'm a completely different computer, very high powered, but I get pretty much the exact same timeout values. Could this be related to the RTD value on the servo? Is there a convenient way to check this register? I didn't see any corresponding read_from_register method for the write_to_register method. Is there one? Maybe the RTD value I tried to set didn't actually take?

from senseact.

Yes. But the DxlCommunicator should set return delay time to zero. To check, you can use the read function.

read_block = dxl_mx64.MX64.subblock('version_0', 'goal_acceleration', ret_dxl_type=use_ctypes_driver)
vals_dict = read(read_block)
print(val_dict['rtd'])  # To print the return delay time

The names for all the DXL MX64 registers in the control table as used in the code are listed here.

Just to clarify, are you using the default cTypes driver written by the DynamixelSDK? The pyserial driver had way more hiccups when we tested it.

from senseact.

OK, I confirmed rtd=0. Yes, I'm using the cTypes drivers.

from senseact.

Has anyone compared using the USB2Dynamixel and the other hardware you guys were using?

from senseact.

Okay, now we know that the @danielsnider's warnings were likely due to using a virtual machine for Ubuntu from Windows.

from senseact.

No repeat of this issue.

from senseact.