|
timetag for variables read?
Alex Brown from United States [10 posts] |
15 year
|
Hi STeven,
I'm going to be running Rocky in the mega line following contest at the club today. While maneuvering such a large robot along a line and detecting the line reliably was a challenge with all the reflections in the hallway, I think I have it working. It took a headlight installation to swamp out the reflections from the overhead florescent lights.
Anyway, I think it will work...except for one intermittent problem I saw yesterday. I am set up to process frames continuously in RoboRealm and to just read COG variables 10 times per second into my control software using the RR_api. The camera is set up to provide about 15 frames per second and appears to do so pretty reliably. I am reading two variables (COG_X from the line right in front of the bumper and another COG_X about a foot farther forward). The symptom is that sometimes the variables freeze for a second or two. This is time enough for the robot to completely depart the line and get lost.
The "getVariables" function is returning with data so it looks like RoboRealm is running during the freeze. But, it looks like either the camera isn't supplying new frames, or RoboRealm isn't processing them or Windows is doing some tricks. Taskmgr says my throughput is only around 20% when everything is running; and my control program is running happily at 10 hz.
I don't know if anything is fixable, but I'd like to know when the data is not being updated. Is there anything I can use to let me know if getVariables is returning stale data? A timetag, frame count or whatever? Then I'd stop the robot quickly when this happens so it could continue when the data resumes.
Thanks,
Alex
|
|
|
|
Anonymous |
15 year
|
Alex,
There are a couple of things that you could have done to test for this case. There is an IMAGE_COUNT variable that indicates the frame count that increments with each image. Checking this variable would indicate if new information is available.
But perhaps the best way is to use the API routine
if (rr.waitVariable("COG_X", value, 100))
{
// new value for COG_X found ... and no timeout was encountered
}
else
{
// timeout exceeded
}
but I'm not sure if you are already using this routine or not? Are you currently just polling for new information AFAP?
You could also use
if (rr.waitImage(100))
{
// new image captured and has been processed
}
else
{
// timeout exceeded
}
in your loop which would ensure that a new image is available (and processed) before continuing the loop and querying for new values.
Note the above timeouts are set to 100ms which might be a little tight ... perhaps 500ms (1/2 sec) might be a better value.
STeven.
|
|
|
|
Alex Brown from United States [10 posts] |
15 year
|
STeven,
I run my Windows program as two main threads; one which handles user interactions and other slow functions like file read/writes etc. and a second thread which performs "realtime" control of the robots motion.
This realtime thread executes every 100 msec (usually pretty close under Windows ;-) and doesn't allow any "waits" which could exceed a few milliseconds. If data isn't available when requested, it takes the appropriate action, e.g. slow down in the case of my line following.
Hence, I think your most applicable suggestion is the Image_count variable. I can read it along with my COG_X variables and know whether the data is fresh.
Only thing that is not completely clear is whether image_count increments after the image is received by RoboRealm, or after the image has been processed. Please let me know.
For your amusement, Rocky came in second in the Mega line following contest. Rocky was the only LARGE robot in this contest designed for larger robots. The other three entries were normal line following size. The other two finishers were Pololu 3pi robots. 3rd place had stock software and was pretty slow. Martin Mason had improved the software in his until it just plain ran fast. Rocky has a top speed of 2 feet per second and had to slow down in corners. Martin's bot just ran flat out at 3 feet per second or so.
I assume you were following my progress in implementing the camera setup on the rssc mail list; the addition of a light source (headlight) swamped out all the reflection problems and he followed the line very reliably. I don't like that solution though, my Halogen light increased the robot's power consumption by 50%. LED lights were suggested.
Thanks,
Alex
|
|
|
|
Anonymous |
15 year
|
Alex,
The IMAGE_COUNT is set before the image is processed ... which is probably not what you want. So a new variable called IMAGE_PROCESSED is set to the same number as IMAGE_COUNT once the image has been processed.
Thanks for the rundown on the RSSC competition. Sorry I missed it!
v2.2.10 has that new variable.
Do you have a sample of an image with and without the halogen light being used? I'm curious how the light improves the image.
STeven.
|
|
|
|
Alex Brown from United States [10 posts] |
15 year
|
STeven,
IMAGE_PROCESSED sounds like exactly what I need. I'll add a test on it to any real time control program that I build.
Sorry, I don't have any images to compare. Basically, with the relatively low lighting in the hall, I have to use as long an exposure as possible while meeting my framerate requirements. This results in the reflection of the overhead lights being very overexposed...pretty much all white.
Even the black tape was all white, although a human can see faint edges of the tape.
Adding the light decreased the exposure time and the reflection didn't so much reach a full whiteout. You could still see the reflection in the image, but it was not as white and the tape was still pretty dark. Hence, robo realm could pick out the tape using canny edge detector.
Thanks, your support is really appreciated!
Alex
|
|
This Thread