[alecw]

And here’s a repackaged version:
https://wirewatcher.wordpress.com/2014/01/29/the-mkii-robot-controller/

I applied the additional 330ohm resistor as suggested here:
http://nootropicdesign.com/forum/viewtopic.php?f=26&t=2540&p=3233

This has made my overlay much brighter.

Thanks for an awesome product!

alec

[alecw]

Hi Michael,

Here’s the controller I’m working on, minus the lid. The whole lot seems to work very well – thanks for your help!

The AV receiver for the wireless camera on the ROV is in the background.

alec

[alecw]

Thankyou 🙂

[alecw]

Yes, I’d come to that conclusion (use analog joysticks) too 🙂

I know the VE uses digital pins 2, 6, 7, 8, and 9 – does it use any analog pins as well?

Many thanks,
alec

[alecw]

Hmm, that’s not as consistent as I’d hoped. It’s better, but I still lose the ability to read the Nunchuck depending on the video signal entering the VE.

I’m sooooo close to getting this working, but I’m running out of things to try.

[alecw]

OK, I’ve put R4 all the way to the right and now the Nunchuck works regardless of what’s on the screen. It also works when Output Select is set to Sync Only.

Does this make any sense at all?

Many thanks,
alec

[alecw]

My washed out overlay was coming from a cheap 900Mhz wireless camera receiver. If I run the receiver into a VCR, then connect the VCR to the VE’s video input, I get a nice bright image.

Hope that helps someone!

alec

[alecw]

Hi Michael,

Should the TVBlaster sample work when the VE’s output select switch is set to Sync Only? It works fine when overlaid over a video stream, but the minute I flick the switch to Sync Only the crosshair stops moving.

Do you know why that might be?

Many thanks,
alec

[alecw]

It’s really quite odd. The Nunchuck also stops responding if I flick the output select switch to “sync only”.

[alecw]

Hi Michael,

Thanks for the tip – I’ll try to make it do less work.

I’m still confused why the work/not-work state is defined by what is on the camera rather than anything else. Could it be anything in my initOverlay() function? I just copied this from one of the other examples, and I don’t really know what it’s doing.

void initOverlay() {

TCCR1A = 0;

// Enable timer1.  ICES0 is set to 0 for falling edge detection on input capture pin.

TCCR1B = _BV(CS10);



// Enable input capture interrupt

TIMSK1 |= _BV(ICIE1);



// Enable external interrupt INT0 on pin 2 with falling edge.

EIMSK = _BV(INT0);

EICRA = _BV(ISC11);

}



ISR(INT0_vect) {

display.scanLine = 0;

}

Do I need to to all of this? I’m not interested in capturing anything, so do I need to do things like “Enable input capture interrupt”?

Many thanks,
alec

[alecw]

Yes, I’m using the HackVision controllers library.

It all works fine, unless I change what the camera is pointing at. Why would what the camera sees affect what I can do with a Nunchuck? Does my code do more than it should? I have no need to capture or process any input, just overlay onto the feed.

Many thanks,
alec

[alecw]

OK, this is strange. Here’s what I hope to be some minimal code:

#include 

#include 

#include 



TVout tv;



void initOverlay() {

TCCR1A = 0;

// Enable timer1.  ICES0 is set to 0 for falling edge detection on input capture pin.

TCCR1B = _BV(CS10);



// Enable input capture interrupt

TIMSK1 |= _BV(ICIE1);



// Enable external interrupt INT0 on pin 2 with falling edge.

EIMSK = _BV(INT0);

EICRA = _BV(ISC11);

}



ISR(INT0_vect) {

display.scanLine = 0;

}



void setup() {

tv.begin(PAL, 128, 96);

Nunchuk.init(tv, 4);

initOverlay();

tv.select_font(font6x8);

tv.fill(0);

tv.draw_circle( 64, 48, 15, 1 );

tv.draw_rect(0,0, 127, 95, 1);

tv.set_pixel( 64, 48, 1 );

}



void loop()

{

Nunchuk.getData();



char joy[32];

sprintf( joy, "= %d = %d =", Nunchuk.getJoystickX(), Nunchuk.getJoystickY() );

tv.print( 0, 0, joy );

}

This seems to work fine, and it puts the X and Y coords on the screen. However, if I point the camera somewhere else (or put my hand up to the lens, which will cause it to turn on its IR LEDs and show a very bright image of my hand), the VE will stop updating the Nunchuck coords. If I remove my hand or move the camera back where it was pointing originally, it starts reading coordinates again.

Any idea why this could be?

Many thanks,
alec

[alecw]

Hi Michael,

Do I have to do anything special to make the TVBlaster sample work on a PAL TV, aside from changing the TV.begin() call? Either the crosshair zooms of to the top right (and won’t come back), or it doesn’t move at all.

Many thanks,
alec

[alecw]

Hi Michael,

Thanks for the reply.

In terms of “if your I2C communication is quick”, all I want to do is read values from the Nunchuk and send it via pollserial. The idea is to make a wireless joystick controller for a bot that is equipped with a 900MHz wireless camera. The camera receiver is attached to the VE, and I’m going to overlay a heads-up-display onto it via the VE. Also attached to the controller/VE is a Nunchuk and an XBee on TX/RX. I want to poll the Nunchuk and send the joystick position to the bot by using pollserial to send it to the XBee (which will send it to the bot, which will act on the values).

Aside from the potential I2C timing issues, it sounds feasible to me, I hope?

If I get it working I’ll write it all up 🙂

alec

[alecw]

Thankyou 🙂

alec

[Author]

Posts