BOSH: Bidirectional Operation over Synchronous Html Data Transfer Method +
The video game industry has done important work on this and we hope game developers will be interested in adding haptic feedback via a robot arm.Latency
The major concern with teleop is the speed of the connection. A fast NodeJS Proxy server takes about 1.6ms between robot and controller. Note: Because NodeJS is known for very rapid response times and the web is a JavaScript heavy house, this seems like a good benchmark environment.
Latency compensation
But as we move out into the internet, latency of hundreds of ms are not unknown. As a result, any robot with a haptic feedback system can get into oscillations or just lag, causing touch feedback to become unusable. The solution is probably to work towards predicting the next movement when sending data from the robot with the human, and predicting forces when sending data back. Obviously, the former is easier than the latter, but 3D scanning the work area and proximity detection before actual touch can help.
Forward Latency compensation
We've already experimented with predicting where the operator is moving the arm via spline curve fitting and it seems like that will work well, but we are concerned about noise in the system and it's needs more testing.
Back Latency compensation
Understanding what forces the remote arm will encounter /in the future/, which is required for latency compensation, is very difficult. Understanding the 3D environment and simulating when the arm will contact an object is one possible approach. Point cloud data is accesable via existing 3D scanners, and can be localized to the end effector to reduce data size. Having to transmit all the points back to the controller is a non-starter; it will be critical to difference the current scan and the prior scan and only transmit errors, or to convert point cloud to mesh, or some combination of that and other tactics.
A critical point is that internet latency increases under load. When sending very low levels of data per unit time, latency is low. When sending large amounts, the latency increases. In general, the data needed to convey the motions, and touch feedback between operator and robot are not a problem.
The issue comes with the transmission of video or other image data. Even when compressing the video, first the compression introduces a computational delay, and even compressed video takes up a very large amount of bandwidth.
One possible solution is to transmit MORE data including 3D scans, with colored voxels or image wrapped (textured) meshes, BEFORE the start of teleoperation, and then only sending changes in that 3D data which are not predicted by the system. By keeping a copy of the 3D data at both local and remote ends, we can predict changes in both datasets and then only transmit from the remote when an updated scan shows changes. E.g. if the robot is moved in the remote scene, update both the local and remote 3D data without transmitting any information aside from the command that moved the robot. The operators view of the remote scene is a re-creation locally by a virtual camera into the synchronised local 3D data set.
| file: /Techref/method/teleops.htm, 3KB, , updated: 2023/9/16 10:57, local time: 2024/11/13 20:24,
owner: JMN-EFP-786,
18.118.27.199:LOG IN
|
| ©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions? <A HREF="http://linistepper.com/Techref/method/teleops.htm"> Methods for Remote Teleoperation of Robotic Motion Systems</A> |
| Did you find what you needed? |