-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
significant delay #31
Comments
Yes, this is pretty much exactly the problem I am having as well. If arm movements are too fast, the skeleton lags behind considerably as you've shown. I was unaware that the 3D projection actually uses the current frame. That would indeed result in quite inaccurate results. If the delay is indeed solely due to openpose, it seems like there's no clear solution other than to find other more efficient methods for skeleton recognition. This is my first time using openpose but I was led to believe that it was more-or-less suitable for realtime operation. |
From what I see, the delay isn't TOO bad (<1 sec). If we can somehow figure out the exact delay from OpenPose, we could feed the old colour/depth images and at least have them sync'd up. Also I'm not 100% sure what I said is the case. This is just my deduction so far from digging into the code, but I'm not deeply familiar with it just yet. |
From openpose forum posts I've read so far, it seems like we should expect a 250 ms or less delay with a good enough GPU. I think the delay exceeds this though. I did notice that in the code the ros header time is assigned by the output worker after the openpose computation. This would result in skeleton frames being published with a time stamp that is later than the actual input time which results in the delay/mismatch. |
Hello @QuantuMope and @chrisywong Thank you very much for bringing up this issue. I was using GTX 1080 with Intel i7 having a 16GB memory machine. My environment details can be found here I don't remember but back then I compiled many packages (even Next, the 3D projection code is not optimized right now. You can see that for each detection keypoint in 2D space, the 3D point is calculated in a sequence. I did use OpenMP but I think that the overhead of creating threads is too much in our case. However, in principle, all 2D points can be converted to 3D using parallel computation to speed up the delay. Another thing you assumed correctly is about the data used for 3D projection in In the past, you may notice in older commits, that I used Other than this, once I remember one person said that Thank you so much. Please let me know the outcome. |
Thanks for the reply @ravijo I'm surprised I will try to use |
Have either of you noticed that the skeleton and point cloud are not aligned in RViz? All points seem to be shifted to the left by about 0.02m. I just want to see if it's a general thing or if it's something related to my setup and/or parameters. I'm using |
Hi, frankly speaking, while writing this package, my application was not expecting large movements and such nice precision. I did not verify this 2cm shift. However, what I have seen that there were some similar-looking TF frames for the camera. Right now, I am using You can echo all TF frames for the camera and there is a possibility that you can find similar TF (no relative rotation and no shift in the z-direction). If so, please change this parameter. I am not so sure though. The other hack can be publishing a child TF of |
@chrisywong |
@QuantuMope Perfect 👍 This is what I was trying to say. It should work. Thanks a lot. |
Hello @chrisywong and @ravijo. I apologize for the late update. |
Hi @QuantuMope Thank you so much for the update. I am glad that the approach worked well on your side. By the way, would you mind making a pull request to share your code? I am thinking to add your contribution to the |
Sure but I just wanted to clarify two things.
Given this, let me know if you'd still like me to submit a pull request. If you'd like the code to stay C++ (since using openpose through Python requires additional compilation steps), if I have some time, I can even convert the code to C++ and submit a pull request then. Just let me know. |
I understand. I think it is all right to submit a pull request for the Python version only. I will create a new branch, say |
Hi @QuantuMope, I'd definitely be interested in trying out your synchronized version! I'm not 100% sure which one I'll end up using for my application, but it'd be good to compare to see which one is more suitable for me. |
If you are in hurry, implementing Meanwhile, we can wait for @QuantuMope for a pull request. |
I apologize for the delay. I am away from my lab for a few days and I want to fully bug-proof the code on a realsense camera before submitting a pull request. I should be back in my lab and be able to get my hands on the camera come this Thursday and will submit it then. |
Have a nice relaxing break @QuantuMope |
@ravijo @chrisywong From tests, latency is greatly reduced on synchronous version but has worse frame rate than the original wrapper so the best version to use will depend on the usage case. |
Thank you so much @QuantuMope I sincerely acknowledge your contribution. The latest commit 0ed2a72 now includes support for the synchronous version provided by you. In the documentation, I quickly added the relevant information under Implementation Versions Info.. Thank you again. You may like to pull the latest changes from the repository. Please let us know if you face any issues. |
Hello @ravijo, Just wanted to notify that I plan on implementing the synchronous node in C++ when I have some free time in the coming weeks. Will submit a pull request when I have it complete and tested. It may be worth keeping both the C++ and Python versions though in case users want to modify the nodes in their language of choice. |
Hello @QuantuMope Thank you so much. Yes, I agree with your suggestion. Thanks again. |
Hi all, I'm trying to use the synchronous script but am running into issues. When I try to run the launch file, I get this error:
I did enable
This occurs on the line Any ideas? Would this somehow be a conflict between having both Python 2.7 and 3.6 on my system? |
First make sure you've successfully built the python openpose. Check the if there is a python folder in your openpose build folder.
in the build folder to install the modules. And if your default python for ROS is python2, you have to make sure you built openpose with python2 too. The default one is python3, you have to change the cmake flag in configuration. |
I did do |
Then it's probably you built a python 3 module but your ROS is looking for a python 2 version. Check the link I pasted before and make sure you build with Python2 executable and libraries. |
Tried building Python 2 vs 3 and still nope. Even pointing to build folder specifically for python 2.7 (and verified version in CMakeCache.txt) |
I think you should point to And maybe you can double check if you have a similar layout like this in your build folder if you run
|
Yes, I am using the absolute path. I just wrote Neither py2.7 nor py3.6 |
pyc file is not important, as long as you have |
Sorry to hear about the issue. Thank you @luorui93 for providing detailed explanations to fix the problem. You have clearly stated all possible ideas! Thanks again. In the case of the First, please switch to
Above, I assumed that you are going to use
To see all python versions available, please type
If you can not import Next, please read the following:
PS: I have reopened this issue. However, I kindly request you to open a new issue with these details. Because this issue, i.e., #31 was originally created for discussion on processing delay. |
Solved this issue, see #41. |
Hello Ravi,
I am using your ros package in an attempt to use openpose for real time skeleton estimation.
The problem is that I am experiencing significant delay between the realtime video feed and the outputted skeleton.
I see from your example gif on the front page README that you were more or less able to get realtime output.
Do you have any idea what could be causing this delay? I am using quite a powerful machine with Openpose 1.6 and a realsense camera. Aside from the delay, the framerate is stable. This leads me to think that this is not openpose related.
Any help would be greatly appreciated.
Thanks in advance.
The text was updated successfully, but these errors were encountered: