Implemented Single-Shot but have problems !!! ON HOLD !!!

This forum is used for discussing hardware, software, and technical details of the AVRcam embedded system.

Implemented Single-Shot but have problems !!! ON HOLD !!!

Postby catalin_cluj » Mon Feb 12, 2007 10:43 pm

!!!Please IGNORE THIS THREAD UNTIL FURTHER NOTICE
I may have found the problem elsewhere, will let you know!!!

Hi John,
I implemented a Single-Shot tracking, by adding a "ST" command to the UIMgr, Executive and the logic mainly in FrameMgr.c.

The problems seem to be that often I don't seem to get a "blob", even though maybe 50% I do, if I ask for it... not too often (by clicking a send button in a win app I wrote, so it can't be too fast).

Another problem seems to be that if I move the tracked object, the next few times I ask for blobs I still get the old position... at least it seems so, and then I get the new position.

I didn't do what you suggested to somebody (only block the TX), instead after each tracking I set the state ti Idle.

I think there's something I'm missing, can you please have a look at this:

>>>
static bool_t bSingleTrack;
void FrameMgr_dispatchEvent(unsigned char event)
{
switch(event)
{
case EV_DUMP_FRAME:
/* try re-initializing the camera before we start dumping */

CamConfig_setCamReg(0x11,0x01); /* reduce the frame rate for dumping*/
CamConfig_sendFifoCmds();
Utility_delay(1000); /* allow the new frame rate to settle */
lineCount = 0;
currentState = ST_FrameMgr_DumpingFrame;
//CamIntAsm_waitForNewDumpFrame(currentLineBuffer,previousLineBuffer);
FrameMgr_acquireLine();
break;

case EV_ENABLE_TRACKING:
currentState = ST_FrameMgr_TrackingFrame;
bSingleTrack = FALSE;
FrameMgr_acquireFrame();
break;

case EV_ENABLE_SINGLE_TRACKING: currentState = ST_FrameMgr_TrackingFrame;
bSingleTrack = TRUE;
FrameMgr_acquireFrame();
break;

case EV_ACQUIRE_FRAME_COMPLETE:
FrameMgr_processFrame();
break;

case EV_PROCESS_FRAME_COMPLETE:
FrameMgr_acquireFrame();
if (bSingleTrack)
currentState = ST_FrameMgr_idle; //Cat make status idle if single Tracking
break;

case EV_SERIAL_DATA_RECEIVED:
if (currentState != ST_FrameMgr_idle)
{
/* we need to go back to processing line data, since
serial data reception interrupted us....just trash the
frame and act like the frame has been processed, which
will kick off the system to wait for the next line */
PUBLISH_EVENT(EV_PROCESS_FRAME_COMPLETE);
}
break;

case EV_DISABLE_TRACKING:
/* tracking needs to be turned off */
currentState = ST_FrameMgr_idle;
break;
}
}
Last edited by catalin_cluj on Mon Feb 26, 2007 11:36 pm, edited 1 time in total.
catalin_cluj
 
Posts: 11
Joined: Sat Feb 10, 2007 4:00 pm

Postby johno » Tue Feb 13, 2007 10:14 pm

I'm not quite sure what you mean by single-shot in this context...do you mean that you want only a single tracking packet for one frame? Or perhaps you only want a single object tracked instead of the max of 8?

Post back with what you are trying to do, and I'll take a closer look.
-John O
Site Admin
johno
 
Posts: 51
Joined: Thu Mar 16, 2006 2:29 pm

Single-Shot

Postby catalin_cluj » Wed Feb 14, 2007 5:30 pm

Sorry, I used a term that was in another thread.
Yes, I want only one tracking packet.
So I implemented a command ST that starts tracking, sends me a packet, and stops everything again (idle).
I don't need to stop the "single-shot" mode.
For some reason it often doesn't work :roll: ... sometimes it does, sometimes it doesn't...

Thanks,

Cat
catalin_cluj
 
Posts: 11
Joined: Sat Feb 10, 2007 4:00 pm

Postby davedave » Fri Feb 16, 2007 11:34 am

One thing that would have helped me a lot when I was trying to figure it out the first time was Kscope (found in (X)ubuntu respository) - C code editor aimed at multi file projects so that you can skip code following function calls with tabbed file viewing. There are several others like it around but it is the best I have seen so far.

I added an event to my version of the code for rangefinding which is a one shot deal but different because it is based off the dump frame code which is already a one shot deal.

I'm sure you've done the same or even identical things but here you are.
My code changes were:
Events.h - #define EV_RANGEFINDING 0x83
UIMgr.c - UIMgr_convertTokenToCmd - else if ( (asciiTokenBuffer[0] == 'R') &&
(asciiTokenBuffer[1] == 'F') )
{
/* the user wants range finding data*/
receivedCmd = rangeFindingCmd;
}
Executive.c -Exec_run - case (EV_RANGEFINDING):
FrameMgr_dispatchEvent(eventGenerated);
break;
FrameMgr.c - enum
{
ST_FrameMgr_idle,
ST_FrameMgr_TrackingFrame,
ST_FrameMgr_DumpingFrame,
ST_FrameMgr_Rangefinding
};

FrameMgr.c - FrameMgr_dispatchEvent - case EV_RANGEFINDING:
/* shameless copy of Johns dump frame code except for currentState */

CamConfig_setCamReg(0x11,0x01); /* reduce the frame rate for dumping*/
CamConfig_sendFifoCmds();
Utility_delay(1000); /* allow the new frame rate to settle */
lineCount = 0;
currentState = ST_FrameMgr_Rangefinding;
//CamIntAsm_waitForNewDumpFrame(currentLineBuffer,previousLineBuffer);
FrameMgr_acquireLine();
break;

FrameMgr.c - FrameMgr_aquireLine - if (currentState == ( ST_FrameMgr_Rangefinding||ST_FrameMgr_DumpingFrame))

FrameMgr.c - FrameMgr_processLine - my own rangefinding stuff which is not even slightly relelvant.

I think that's all that I had to change. I'd suggest you do something similar but you would work with the FrameMgr_aquireFrame and FrameMgr_processFrame for your processing. Perhaps you could just follow the current tracking code stream through those functions but put this just before the end of FrameMgr_processFrame.

if(currentState==ST_FrameMgr_singleTrack) PUBLISH_EV(EV_DISABLE_TRACKING);
else PUBLISH_EV(EV_FRAME_COMPLETE);
davedave
 
Posts: 15
Joined: Wed May 10, 2006 11:02 pm
Location: Canberra Australia

John, I need your help.

Postby catalin_cluj » Sat Feb 24, 2007 12:02 am

Let's say I need 2 tracking info at 200ms between them, but I may need to change the color map in between, so I'd prefer to not stay in normal tracking mode.
This timing is important to me, and it may vary.

With the changes I made, I can get a "one shot" tracking info, as described, but for some reason, I always get a tracking info of the previous position first...

Like this:
I get a shot (1st frame of interest), let's say it's OK.
I move camera, so next tracking info should move.
I ask for a shot (2nd), I get it in the old position.
I ask for another one (3rd), I get it in the new (good) position.

It's like... after I request a single shot, it gets another frame, but doesn't process it until I ask for the next shot, when it gives it to me, even though it's old...

Or like the sensor itself (OV6620) becomes idle but keeps the old image in it's own buffers and "serves" it to the mega8 when it's un-idled.
But I thought the sensor always runs, it's just the mega8 that reads the frames or not... am I wrong here?

What does the camera "do" when it's idle? I feel like it sleeps somewhere after it processed a tracking frame, but before it sends it out...

How can I make it flush the old frame (2nd), ideally immediately after the first frame of interest (1st), not just before the wanted one (3rd)?

HELP?
Thanks,
Cat
catalin_cluj
 
Posts: 11
Joined: Sat Feb 10, 2007 4:00 pm


Return to AVRcam Embedded System

Who is online

Users browsing this forum: No registered users and 18 guests

cron