Closed Saman-Khan closed 2 years ago
Here's the time obtained after simulating multiple cases
The behavior runs at the frequency of the camera images which is only 60Hz instead of 83Hz, so on average about 2 out of 8 simulator frames will not have a corresponding cognition frame.
There is indeed a problem that the simulation behaves differently under different load conditions. Basically the robot controller is only synchronized one-way, such that the simulation blocks as long as the sensor values from a specific frame haven't been passed to the robot software, but there is currently no synchronization in the other direction, i.e. some of the joint requests from the robot software may not reach the simulator. This can lead to drastically different walking behavior depending on the simulation speed.
So, there is no way, reliability can be achieved? For analyzing that one behavior is faster than other, time analysis wont offer concrete results. As the time analysis would be dependent on cpu load conditions, parameters other than time should be looked for , to get reliability. The maxSpeed for robot in code is stated as 200mm/s however , as per above analysis, the speed turns out to be 140-160mm/sec , so i believe using it 200mm/sec would lead to wrong estimates. or the less speed i am getting might be due to cpu loads. Can it be concluded that walk engine has fixed speed to reach same point(distance of 1m lets say), irrespective of the direction from which it is approaching? the long sideways walk for longer distance doesn't really seem line actual player behaviour as humans generally change orientation and run forward in Game.
The simulator is not really a useful tool to optimize motions and not tuned for realism.
With the walkToPose motion request (which is wrapped by the WalkToPoint skill), the robot will turn and walk forwards instead of sidewards for longer distances, as long as long as the disableAligning parameter is not set. For short distances, it often does not make sense to spend the time on turning first. On the real robot, walking sidewards can even be faster than walking forwards.
Thanks a lot for your reply. If you can please clarify the range for short distance, e.g is 1 m short or long as per your perspective. You are free to close this issue if u don't want to answer this or its against your terms. Sorry for bothering u but your team really helped. Thanks again
The algorithm to decide the next foot placement from a given target is in this file: https://github.com/bhuman/BHumanCodeRelease/blob/coderelease2021/Src/Modules/MotionControl/WalkingEngine/WalkToPoseEngine.cpp
The boundary is somewhere between 60cm and 1m, but in general the behavior also depends on close obstacles.
Hi, in simulation environment, I wanted to analyze the behavior of walk engine ( time taken by WalktoPointSkill to reach 1m distance specified at different angles from robot starting point) For some cases, the robot don't turn by moves sideways to reach a point. To note the time, I used printing the state_time on console using OUTPUT_TEXT command. If in a particular state, the state_time is printed in every iteration, it miss some values e.g the time will be ( 0,12,36,48,60,72,84,108...) 24 and 96 got skipped. This might be due to console printing. The same happens when simulation of time is set to on using st on command. One issue is , i was running multiple cases to average out the value. I ran almost 90 simulations. By the end , the time to reach (500,-866) starting from (0,0) was near 11 second. Today , on reopening the laptop, the state_time for same conditions is approx 8.5 seconds. I am figuring out the cause of delay to be due to cpu load. How to get reliable estimates using simulator? I am running BHFast script. Any lead would be highly appreciated. Apologies in advance for any inconvenience caused.