Hello,
We have bought 10 cameras between M0011xxx to M0012xx, and we added 5 M0018xx cameras recently. Because we can't run additional cameras properly in Tracking tools 2.3.1, we upgraded Tracking tools from 2.3.1 to 2.3.3 which supports S250e cameras with serial M001694 or higher.
After the upgrade, Tracking tools itself works good. All cameras are detected. But sample source (markers.sln) in this version, and also our previous program doesn't work. The order of camera numbers appeared in sample program are different from that of Tracking Tools, and registered trackables are not detected. This fault in camera may cause tracking errors. We also tested 2.3.4b, but this version doesn't accept camera vision properly.
Have you got an idea how to resolve it ?
Thanks a lot
Tracking Tools (2.3.3) can't track trackables in sample
-
- Posts: 1896
- Joined: Tue Feb 01, 2011 8:41 am
- Location: Corvallis, OR
Re: Tracking Tools (2.3.3) can't track trackables in sample
Have you recompiled against the new included libraries?
What issues are you seeing with camera numbering? Do they appear before or after loading a calibration file?
What issues are you seeing with camera numbering? Do they appear before or after loading a calibration file?
Re: Tracking Tools (2.3.3) can't track trackables in sample
Hi, Mike.
I ran into a problem that seems to be similar to the one Hiroosa is (was?) having. Background: I set up a mock system with only three S250e cameras, so that I could play around with the Tracking Tools API for a bit; by the way, I'm using Tracking Tools v2.3.4b1. Everything is working very well within the actual software. Loading a previously created project takes maybe 5 seconds (Core i3, 6 GB memory, Win7-64), the system perfectly recognizes both rigid bodies I created (3 markers per body), and the camera ids are 1, 2, and 3.
When loading the same project with the example solution that came with the Tracking Tools ("markers"), the example program takes 30+ seconds to start up, it can't track any rigid body, and it doesn't even find any markers despite that the rigid bodies weren't even moved. Surprisingly, camera ids are either 1, 3, 5, or 2, 4, 6. I'd really like to give you more feedback on the camera behavior but it's kinda inconsistent (sometimes the red LED on all three cameras flash synchronously; sometimes the red LED on one camera is on, while the ones on the other two cameras are off; sometimes all three cameras display 'UP', sometimes they don't). It certainly would be helpful, if there would be a reference manual that describes what the different status messages on the cameras actually mean... (hint, hint!). Anyways, the reason why the example program takes so long to start up is that TT_Update returns NPRESULT_NOFRAMEAVAILABLE for quite a while. Unfortunately, that's pretty much all I can tell but if you need my project file or screen shots or whatever, please let me know. It would be great if you could look into this problem cause I'm really psyched to use the system for my research.
Cheers,
Adrian
I ran into a problem that seems to be similar to the one Hiroosa is (was?) having. Background: I set up a mock system with only three S250e cameras, so that I could play around with the Tracking Tools API for a bit; by the way, I'm using Tracking Tools v2.3.4b1. Everything is working very well within the actual software. Loading a previously created project takes maybe 5 seconds (Core i3, 6 GB memory, Win7-64), the system perfectly recognizes both rigid bodies I created (3 markers per body), and the camera ids are 1, 2, and 3.
When loading the same project with the example solution that came with the Tracking Tools ("markers"), the example program takes 30+ seconds to start up, it can't track any rigid body, and it doesn't even find any markers despite that the rigid bodies weren't even moved. Surprisingly, camera ids are either 1, 3, 5, or 2, 4, 6. I'd really like to give you more feedback on the camera behavior but it's kinda inconsistent (sometimes the red LED on all three cameras flash synchronously; sometimes the red LED on one camera is on, while the ones on the other two cameras are off; sometimes all three cameras display 'UP', sometimes they don't). It certainly would be helpful, if there would be a reference manual that describes what the different status messages on the cameras actually mean... (hint, hint!). Anyways, the reason why the example program takes so long to start up is that TT_Update returns NPRESULT_NOFRAMEAVAILABLE for quite a while. Unfortunately, that's pretty much all I can tell but if you need my project file or screen shots or whatever, please let me know. It would be great if you could look into this problem cause I'm really psyched to use the system for my research.
Cheers,
Adrian
-
- Posts: 1896
- Joined: Tue Feb 01, 2011 8:41 am
- Location: Corvallis, OR
Re: Tracking Tools (2.3.3) can't track trackables in sample
How are you initializing the system?
Re: Tracking Tools (2.3.3) can't track trackables in sample
Hi, Mike.
As I said, I'm basically using the example called "markers".
I started with calibrating the system and defining two rigid bodies ("left", and "right") using the Tracking Tools; before exiting the program, I saved the project file.
After that, I ran the "markers" project. It's basically the following code:
The output / return values are as follows:
Again, the camera ids were 1, 2, 3 while using the Tracking Tools, and 2, 4, 6 while running the "markers" program. An important detail might be that it took ~1150 calls to TT_Update before it returned NPRESULT_SUCCESS and not NPRESULT_NOFRAMEAVAILABLE anymore (1150 cycles * 20 ms / cycle = 23s). As I wrote before, loading the project in the Tracking Tools and tracking both rigid bodies takes just under 10 seconds.
I hope this information is somehow helpful. If you need any additional details, please let me know!
Cheers,
Adrian
As I said, I'm basically using the example called "markers".
I started with calibrating the system and defining two rigid bodies ("left", and "right") using the Tracking Tools; before exiting the program, I saved the project file.
After that, I ran the "markers" project. It's basically the following code:
Code: Select all
NPRESULT result;
result = TT_Initialize(); //[1]
result = TT_LoadProject("C:\\Users\\hcilab\\Desktop\\Project.ttp"); //[2]
for(int i = 0; i < TT_CameraCount(); i++) printf("Camera #%d: %s\n", i, TT_CameraName(i)); //[3]
for(int i = 0; i < TT_TrackableCount(); i++) printf("Trackable #%d: %s\n", i, TT_TrackableName(i)); //[4]
int mFrameCounter = 0, mUpdateCycle = 0;
while(!_kbhit())
{
result = TT_Update();
if(result == NPRESULT_SUCCESS)
{
printf("Update #%d | Frame #%d | Markers %d)\n", mUpdateCycle, mFrameCounter, TT_FrameMarkerCount()); //[5]
for(int i = 0; i < TT_TrackableCount(); i++)
{
float x, y, z, qx, qy, qz, qw, yaw, pitch, roll;
TT_TrackableLocation(i, &x, &y, &z, &qx, &qy, &qz, &qw, &yaw, &pitch, &roll);
//[6]
if(TT_IsTrackableTracked(i)) printf("%s: Pos (%.2f,%.2f,%.2f)\n", TT_TrackableName(i), x, y, z);
else printf("%s: Not Tracked\n",TT_TrackableName(i));
}
mFrameCounter++;
}
mUpdateCycle++;
Sleep(20);
}
result = TT_Shutdown(); //[7]
result = TT_FinalCleanup(); //[8]
Code: Select all
[1] NPRESULT_SUCCESS
[2] NPRESULT_SUCCESS
[3] Camera #0: OptiTrack S250e M001992
Camera #1: OptiTrack S250e M001996
Camera #2: OptiTrack S250e M001993
[4] Trackable #0: Left
Trackable #1: Right
[5] Update: #1171 | Frame #0 | Markers: 0
[6] Left: Not Tracked
Right: Not Tracked
[7] NPRESULT_SUCCESS
[8] NPRESULT_SUCCESS
I hope this information is somehow helpful. If you need any additional details, please let me know!
Cheers,
Adrian
Re: Tracking Tools (2.3.3) can't track trackables in sample
That sounds like an issue of some kind. I will add it to our database and take a look at it. In the meantime, I would suggest instead of loading a project, try doing things. Initialize the TT API and wait until you have all 3 cameras connected. Then load the calibration & trackables files. This will get you tracking until I can see what is going on here.
Re: Tracking Tools (2.3.3) can't track trackables in sample
Hi, Doug.
Thanks for your suggestion. I started moving function calls around, and I guess I figured out what was going on: after putting TT_LoadProject inside the if(result == NPRESULT_SUCCESS) statement, the system magically started to work properly. I suppose you shouldn't load the project file before the cameras are either synchronized or timed out.
Thanks a lot for your feedback; maybe you might wanna update your example for the next release, though, so that other people won't run into the same problem.
Cheers,
Adrian
Thanks for your suggestion. I started moving function calls around, and I guess I figured out what was going on: after putting TT_LoadProject inside the if(result == NPRESULT_SUCCESS) statement, the system magically started to work properly. I suppose you shouldn't load the project file before the cameras are either synchronized or timed out.
Thanks a lot for your feedback; maybe you might wanna update your example for the next release, though, so that other people won't run into the same problem.
Cheers,
Adrian
Code: Select all
NPRESULT result;
result = TT_Initialize();
bool isInit = false;
int mFrameCounter = 0, mUpdateCounter = 0;
while(!_kbhit())
{
result = TT_Update();
if(result == NPRESULT_SUCCESS)
{
if(!isInit)
{
result = TT_LoadProject("C:\\Users\\hcilab\\Desktop\\Project.ttp");
isInit = true;
}
// do stuff
}
mUpdateCounter++;
Sleep(20);
}
result = TT_Shutdown();
result = TT_FinalCleanup();