- This topic has 15 replies, 5 voices, and was last updated 10 years, 2 months ago by
.
-
Posts
-
Hi again,
I have been having a problem with the overlay of the the experimenter board. It will sometimes wink out of existence for no reason and the overlay will disappear when a bright object has been moved around in its field of vision for more than 20 seconds when using the Object Tracking program.
Could there be a known reason for this? I’d just like to know if it could be a known error, if not could it be a memory overload for whatever reason? If so, is there a way I can cut back on the used memory even though the IR camera already displays in monochrome? (the program’s current memory usage in 13,563 bytes out of 32,256 – not counting the camera’s requirements for processing) on the Uno so should i add SRAM extensions? However, SRAM extensions would require interfacing that would apparently interfere with the VE board (since it can’t take I2C communication?). Could you advise me on this and I2C communication?
NOTE: I have read the other post concerning this problem, I believe it has something to do with the fact that Object Tracking is one of the larger programs (byte wise)
Thanks,
RobotixIf anyone else encounters this problem, a soft-reset will solve it. Wire a PWM pin to the the Reset pin (RST on this board) and set it to low when you wish to reset it:
analogRead(PWMpin, LOW);
This is not recommended by the Atmel designers, because it may get stuck in a cycle of resetting, so give a reasonable delay time (>12s) between each reset. Watchdogs won’t work so I would not suggest that. This is definitely a buffer overload, although i’m not sure what is causing it. I’ll update if I find out.
If you need to do other things with the board, I would recommend I2C communication (using the appropriate TVout specialized version) with another board.
Having the same problem, any further resolution? Would you mind posting your code to allow periodic soft-reset of the board? Thanks!
I too am having the same problem.
The Video Experimenter board works great for about 30 seconds then the overlay stops. I put a Serial.print command in the code to spit out the x,y coordinates and they also stop getting spit out after 30 seconds.
I am using the code example to get familiar with the board, but it seams to stop working after 30 seconds. I reset it and it works for 30 more seconds.
The camera I am using is black and white with a composite video out with 720 x 480 lines. Could this be a problem?
I should mention, that I am only trying to track the bright spot, just like the demo code does in the video on the site. I am using a laser as the bright spot. I tried red and green wavelengths with the same result.
New Results:
I just found out that if I unplug the camera input and plug it back in (without resetting the board) the overlay starts working again along with the Serial.print output I put into the code. I guess it must have something to do with the camera.I will post debug info as I begin to understand what is happening. Anyone with more info, please post. Would love for this to work without major debug.
Thanks,
-MattYou can’t use Serial output while generating video. Use the pollserial library that comes with the TVout library. If the microcontroller is being forced to handle serial communication interrupts, then it will interfere with the video.
Has anyone figured out what is causing this buffer overrun? Another piece of evidence that lends to this theory is that I added to the program size by keeping track of the amount of pixels that were “lit” (I used a count++ for every pixel that was found to be “true” in the x,y loop). This made the program crash after a few seconds instead of the usual minute or so.
Are you trying to use the Serial library in your program? You cannot use it. You MUST use the pollserial library that comes with TVout if you want to print debugging info the the serial port.
I’m not. It was using the vanilla sketch from the site. I added the on pixel count thing later then took it off.
Is there a way to use pollserial to send exceptions thrown out the serial port?
You can write whatever diagnostic output you’d like out to the serial interface using pollserial. There’s no such concept as exceptions in embedded electronics though. It’s C code running on raw metal, so if your program is incorrect or if you blow the stack or stomp on memory, there’s no OS underneath you to tell you that. Make sense?
I’m not sure what’s wrong with your setup, but maybe your video source doesn’t give a clean sync signal.
That’s possible, I don’t know how strict my video source is. I’m using a Nikon D5200’s AV output. I have a CMOS camera I bought from eBay that I’m not using because I forgot to get a BNC cable at Fry’s but tomorrow I’ll try it.
I get your point about the missing underlying OS managing exceptions. Maybe there was some remnant on the bootloader left behind to do that sort of task, but I suppose that would be poor design on a hobbyist kit with very limited resources. I could also see advanced programmers wanting to reclaim those resources back if such a thing were in there.
I’ve heard of people using Microsoft Visual Studio to run advanced debug tools on the code, maybe I can use those to peek behind the scenes? I’m afraid the need for timing to properly capture frames would break with breakpoints and the variables wouldn’t represent actual values from a clean runtime.
There are ways to debug the ATmega328 MCU using JTAGICEmkII or Dragon programmers, but I have not done it. I typically use the old-school printing of info to the serial port in order to debug problems. You are right that breakpoints are going to destroy the ISR timing.
PLEASE understand that the Video Experimenter is a very inexpensive and relatively crude device — it’s just a sync separator and some clever code. Generating video from a $1.63 microcontroller requires a great deal of the microcontroller’s resources, so there are some real limitations to what you can do practically.
I understand, if I were able to squeeze a little bit more it would do everything I sought to do with it. And if I can’t, I’m still super satisfied because it’s taken me farther than I ever will with an Arduino.
Is there a way to figure out what reference voltage is going into the analog comparator? Or is there a way to give the Arduino a reference voltage manually by feeding the comparator with a PWM?
The 10K pot controls the analog reference voltage for the comparator. PWM generates a square wave, not a voltage between 0-5V, unless you filter it with a cap. You could try using PWM on timer2 or timer0 with a filtering cap to generate an analog voltage, but I don’t think it would be very steady. Many people think that analogWrite generates an analog voltage, but it does not. PWM is a square wave.
Okay. At 5V, with a 10k resistor and a 10uF cap I can get about a .02 delta V from peak to peak (http://sim.okawa-denshi.jp/en/PWMtool.php). Do you think that would be stable enough? Then I can adjust the duty cycle of the PWM to adjust the cutoff voltage for pixel brightness.
Since the Arduino doesn’t run at exactly 5V unless the voltage regulator is awesome, would the TVOut library be compatible with sampling the input voltage so I can read the analog input from the PWM to ensure that it’s simulating the correct voltage? I ask because the most accurate methods I’ve found for sampling voltage involve using the Arduino 1.1V reference, which in turns requires the use of the analog comparator. (e.g. http://provideyourown.com/2012/secret-arduino-voltmeter-measure-battery-voltage/)
- You must be logged in to reply to this topic.