Any idea about sending velocity command?

[zhaozhongch]

Thanks for this great repo. I am currently using it to check its performance against the real spot. In this repo, the way to control the robot, for example, in the teleop_rs_keyboard.py, is sending commands like steplength and the yaw rate. In the real spot, the command to control the robot is like velocity_command(https://dev.bostondynamics.com/_modules/bosdyn/client/robot_command), which needs three main input, the velocity in x-direction, y-direction, and the yaw rate. Is there any way to replace the steplength command by the v_x and v_y so that the virtual spot can receive a command more like the real spot?

Thanks!

[tarasborov]

Hello @zhaozhongch! Thank you for your feedback! It is really appreciated. The teleop_rs_keyboard.py is an adapted version of a teleop for MIT control algorithm. If you want to control Spot via v_x and v_y command use our realised package teleop_legged_robots: 1) https://github.com/SoftServeSAG/teleop_legged_robots 2) https://www.youtube.com/watch?v=Oy3aWgkpuaM 3) http://wiki.ros.org/teleop_legged_robots

[tarasborov]

At that moment, the package spot_control is not adopted for v_x and v_y command. I will add this feature next week.

[zhaozhongch]

Thanks! I am looking forward to that

[tarasborov]

Hello @zhaozhongch! I would like to let you know that the package was updated and now Spot can be controlled by Twist() and Pose() messages. For that, you can use our teleop http://wiki.ros.org/teleop_legged_robots. The details are given in Readme.md. i should note that is the initial stage of such integration and the solution can be improved. Thanks!

[zhaozhongch]

Thanks, I really appreciate it! I'll check it out soon and if I find any bugs to fix or anything to improve I'll let you know

[zhaozhongch]

I test the current commit. I found the robot can move backward without a problem but is hard to move forward. There should be some bugs but I didn't find them yet. I upload two short videos, in the first video, I set the swing period to 0.09 because I found this value can make the robot move more stable. I first press , several times then press the i several times (as you can see in the video's bottom right terminal) https://www.youtube.com/watch?v=373p6tlotFY When the robot moves backward, it works nicely but when I press ,, it was supposed to move forwards but it still moves backward.

In the second video, the swing period is set as the default value 0.17, when I press , several times, it still can move backward but when I press i it directly falls down. https://www.youtube.com/watch?v=rqlcR32hIYs Happy to discuss this!

[tarasborov]

Hello! Thank you for your feedback. It looks strange because it works correctly on my machine: https://www.youtube.com/watch?v=Ec663bhAVq4 . Please, make sure that you run that latest version.

[tarasborov]

Also, please check whether the elapsed_time is not bigger than spot_control.time_step in env_tester.py. If yes, then the gait generator is not synchronized with simulation time. Then, you can play with sample time and swing period.

[zhaozhongch]

Hi. I download the package yesterday so I guess it is the latest version. I noticed in your video it seems the swing period is pretty small so I decrease the self.Tswing even more. Now I set the self.Tswing to 0.03. Then the robot moves more stable. However, I still didn't get any luck when I press i, the robot still moves backward. The elapsed time is around 0.05 and the time step is 0.01. I guess this is OK? Just record some value

('elapsed time and time step ', 0.05591893196105957, 0.01)
('elapsed time and time step ', 0.06152200698852539, 0.01)
('elapsed time and time step ', 0.05583786964416504, 0.01)
('elapsed time and time step ', 0.05920886993408203, 0.01)
('elapsed time and time step ', 0.05641484260559082, 0.01)
('elapsed time and time step ', 0.059532880783081055, 0.01)
('elapsed time and time step ', 0.055999040603637695, 0.01)
('elapsed time and time step ', 0.04433894157409668, 0.01)
('elapsed time and time step ', 0.0490260124206543, 0.01)

Also I make sure the five commands I run in five terminals to control the robot are correct

roslaunch rs_gazebo HQ.launch    //gazebo world
roslaunch rs_gazebo robot.launch   //spawn the robot
roslaunch rs_inverse inverse.launch  //start inverse kinematics
roslaunch rs_base quadruped_controller.launch //start controller
roslaunch teleop_legged_robots teleop.launch //start keyboard control

I start to doubt if in a different CPU the behavior will be different? I'll try this on a different laptop to see if I get some luck. Thanks anyway! The package is great

[zhaozhongch]

This may sound not like a reason...I have reset the Tswing = 0.17, your default value. When I work, I normally connect my laptop to one more screen. I found when I start all the programs and I didn't connect my laptop to another monitor, the spot can move forward without a problem. The following behavior is just I keep pressing i https://www.youtube.com/watch?v=r_MLWsHbzpQ However, when I connect to another monitor, restart all the launch files, and keep pressing i, the robot behavior is like the following video. It falls down directly https://www.youtube.com/watch?v=Hw1gTQIlXTg

I found the above behavior accidentally. I carefully checked it several times, i.e. run the program with/without another monitor connection, and found it is indeed the case. If one more monitor really matters, I feel like it has something to do with the GPU. My laptop GPU is RTX1050 Ti. This is really wired but anyway, the moving forward control works now :)

[tarasborov]

It is great that all works now. The reason is that the elapsed time should be in several times smaller than the swing period because in each computational step each point of 12 Bezier gait is calculated.