This project consists of a small robot simulator, featuring a 4-DoF robotic arm, and a three-fingered gripper end effector.
Compilation should be fairly straightforward: just run cargo build
on any system with a recent-ish Rust installation.
If you have Nix installed, the shell.nix will provide you with an
environment with the required Rust binaries.
For ease of use, every tagged version of the code is automatically compiled. Pre-compiled versions can be found in the releases, which should simply run out-of-the-box on most Windows, OSX and Linux systems.
To enable remote-control mode, apply the --remote_control_port <port> option
when running the simulator, where <port> is an available TCP port of your choice.
The simulator will then bind to that port, and pause until a client connects to it.
Upon connection, the client will receive exactly 8 + 10*4 bytes. These represent a
single 64-bit unsigned integer, and 10 32-bit floats, all in big-endian order.
The integer is the number of time steps have elapsed in the simulator and starts at 0, the first instance of which will be 0, after which it increments by 1 every frame. You can use this property to verify whether frames are being decoded correctly.
The 10 floats are joint angles in radians, in the range [-pi,pi], which correspond to the following joints:
- The swivel at the base of the robot.
- The hinge at the base of the robot.
- The hinge in the middle of the arm.
- The hinge at the "wrist" of the end effector.
- The hinge at the base of the first finger.
- The hinge at the base of the second finger.
- The hinge at the base of the third finger.
- The hinge at the middle hinge of the first finger.
- The hinge at the middle hinge of the second finger.
- The hinge at the middle hinge of the third finger.
The client then MUST send back 10 32-bit big-endian floats, representing the target rotational velocities of every joint, in the same order as the ones before.
The simulator will then take a single time step, and send joint angles again, in the same format, continuing the same behavior in a loop.
The simulator will not advance until it has received the target velocities, and thus will advance by exactly one time step for every set of velocities, keeping it in sync with the client.
While this is not currently verified, the simulator should be deterministic if supplied with the same velocities.
An example file of a simple python script that works with the simulator is provided: external_controller_example.py