Any interest in NES ROB homebrews?

[Pioneer4x4]

On a side note, I have been thinking of this myself, and this thread helped me a bit with some of the other commands such as "reset to home".

Here is a list to my latest progress. I have full control of the R.O.B. from my Atari 2600. So I think it is safe to assume that it is possible from any classic console on a CRT.

I confirmed all of the codes mentioned as well.

http://www.atariage.com/forums/topic/190214-i-got-my-atari-to-control-my-nintendo-rob-robot/page__p__2406378?do=findComment&comment=2406378

[unoclay]

Hello,

 

I was googling around the net and found this thread. I'm an owner of a working R.O.B. and have the requisite non-LCD television with which he functions. I am NOT a programmer and not much help with regard to the primary discussion here, but I would gladly lend my help in any way to see a ROB homebrew produced. I'd also pay a reaonable amount for my copy of the final product. ;'] I could assist with ideas, test run carts, ?? whatever.

 

This thread is almost a year old and probably dead, but if anyone wants to get in touch with me on this subject, drop me a line at unoclay AT hotmail DOT com. Not a regular viewer of this forum, though I occasionally pop in for a read.

 

Thanks for inspiring my hope that R.O.B. isnt dead.

[infinitr]

Hello,

 

I had to bring this thread back to life. I am trying to wake up a R.O.B. and found this. There is some good info here that I was able to get some use out of, though not yet a consistent result.

 

I'm taking a little different approach. I went on the notion that the refresh rate of current monitors is the issue. So I decided to try to use an Arduino to pulse an LED in the eye of R.O.B. using the info posted here. Note that the LED needs to be pointed directly into the eye. I used a yellow one, but don't have a lot of info about the other colors yet.

 

It works, but there are still some issues I am not sure how to solve. I was able to sort of tune the delays using an analog potentiometer until the robot responded.

 

The initialization part seems to work fairly well as the LED on his head flashes, and sometimes he will make a move but it is not usually what I expect. The timing of the delays may be the issue, and there is likely a better use of a timer to get consistent pulses. I hope if anyone knows AVR or Arduino they can chime in and help tighten this up.

 

He is responding though so there is a possibility to give an input that will use an LED to pulse the correct signals.

 

This is what I have right now, it's a bit messy because I am just hacking back and forth. Keep in mind there are a few different delay variables that I was experimenting with because I noticed that a delay at half the rate for the action section was causing motions. Again I am not sure if this is just a result of the timer being off

 

Any further help is appreciated.

int potPin0 = A0;    // select the input pin for the potentiometer
int potPin1 = A1;    // select the input pin for the potentiometer
int ledPin = 13;      // select the pin for the LED
int delayTime =30;  // variable to store LED delay 1
int delayTime2 = delayTime/2;  // variable to store LED delay 2
int delayBetween = 0;  // variable to store a delay between Init and Action

void setup() {
  
  Serial.begin(9600);
  // declare the ledPin as an OUTPUT:
  pinMode(ledPin, OUTPUT);  
}

void loop() {
   
  RobMove(); 
//delayTime = analogRead(potPin0);
//delayTime2 = analogRead(potPin0); 
//delayBetween = analogRead(potPin0);  
Serial.print("Delay 1: ");   
Serial.println(delayTime);
Serial.print("Delay 2: "); 
Serial.println(delayTime2);
Serial.print("Delay Between: ");
Serial.println(delayBetween);
Serial.println(""); 

 delay(2000); 
}


///FUNCTIONS

void RobMove ()
{
bool Init[] = {0,0,0,1,0};
bool Action[] = {1,0,1,0,1,0,1,1};
    
    //Initialization
    for (int i=0;i<sizeof(Init);i++){
      if (Init[i]==0){
        digitalWrite(13, LOW);   
        delay(delayTime); 
      }
      else{
        digitalWrite(13, HIGH);   
        delay(delayTime); 
      }
     
    }  

    //delay(delayBetween);
    
    //Action
    for (int i=0;i<sizeof(Action);i++){
      if (Action[i]==0){
        digitalWrite(13, LOW);   
        delay(delayTime2); 
      }
      else{
        digitalWrite(13, HIGH);   
        delay(delayTime2); 
      }
     
    } 
    
    //Reset LED OFF
    digitalWrite(13, LOW);
    
}


//Other test functions

void RobCalibrate()
{
delayTime = 30;
delayTime2 = 18;
//delayTime2 = analogRead(sensorPin);  
//Serial.println(delayTime2); 

  //----------------
digitalWrite(13, LOW);   
     delay(delayTime); 
     
     digitalWrite(13, LOW);   
     delay(delayTime); 
     
     digitalWrite(13, LOW);   
     delay(delayTime); 
     
digitalWrite(13, HIGH);   
     delay(delayTime);  

digitalWrite(13, LOW);   
     delay(delayTime); 
     
     //-----------------

digitalWrite(13, HIGH);   
    delay(delayTime2);  

digitalWrite(13, LOW);   
     delay(delayTime2);   

digitalWrite(13, HIGH);   
    delay(delayTime2);  

digitalWrite(13, LOW);   
      delay(delayTime2);   

digitalWrite(13, HIGH);   
      delay(delayTime2);  

digitalWrite(13, LOW);   
      delay(delayTime2);    

digitalWrite(13, HIGH);   
      delay(delayTime2);  

digitalWrite(13, HIGH);   
       delay(delayTime2); 
     
     
//-------



}


void RobTest()
{
delayTime = 30;
// delayTime = analogRead(sensorPin);  
//Serial.println(delayTime); 

  //----------------
    digitalWrite(13, LOW);   
    delay(delayTime);

digitalWrite(13, LOW);   
    delay(delayTime);

digitalWrite(13, LOW);   
    delay(delayTime); 

digitalWrite(13, HIGH);   
     delay(delayTime);  

digitalWrite(13, LOW);   
     delay(delayTime); 
     
     //-----------------

digitalWrite(13, HIGH);   
    delay(delayTime);  

digitalWrite(13, LOW);   
     delay(delayTime);   

digitalWrite(13, HIGH);   
    delay(delayTime);  

digitalWrite(13, LOW);   
      delay(delayTime);   

digitalWrite(13, HIGH);   
      delay(delayTime);  

digitalWrite(13, LOW);   
      delay(delayTime);    

digitalWrite(13, HIGH);   
      delay(delayTime);  

digitalWrite(13, HIGH);   
       delay(delayTime); 
     
     
//-------
       
}

Edited January 10, 2016 by infinitr

[Pioneer4x4]

I skimmed your code and I see several references to the patter for init and reset, but nothing else. the 0s should be off, and the 1s should be on, with the same rate as the screen refresh rate on the atari. Basically from what I remember it was paint the screen black and do a drawscreen in bbasic, the change to white and drawscreen for 1. Is that 30 or 60hz, I forget. I still have my source code I said I would release back in 2011 if anyone is interested, or has it already been dumped and released?

[infinitr]

Thanks for the reply.

 

The lines

digitalWrite(13, HIGH);
delay(delayTime);

Turn the LED light on

digitalWrite(13, LOW);
delay(delayTime);

Turn the LED light off

 

In the Arduino world, setting a pin HIGH and LOW is similar to flipping a power switch on and off. 13 happens to be the number of the pin that I am switching. The Arduino has several pins (Digital Input/Outputs) that can be used to control various devices such as lights, circuits, motors, etc. I'm loading the 0's and 1's into an array, and then using a loop to cycle through the values. If it's a 0, the LED light turns off. If it's a 1, the LED light turns on. Then I am using the delay to tune the timing between the 0's and 1's to try to match the rate necessary to communicate with ROB.

 

Effectively, it's the equivalent to a black screen and a white screen, except rather than flashing a screen I am just flashing an LED light at ROB. I'm definitely interested in whatever you can provide...I'm not so much interested in gaining anything from it other than cracking the code and bringing this technology back to life.

Edited January 13, 2016 by infinitr

[ta0]

I got a Rob and Gyromite.

I used a high speed camera (480 fps or 8x the TV rate) to look at the actual output from the TV. I got the same codes as Tursi. The instructions are given one per frame, at 60 fps. There is no black frame after outputing the instruction. The test sequence that flashes the LED on the head is: 00000 000101 1101011 11111.

 

I would think that having the correct timing is pretty important (although I would guess that R.O.B. still works with 50Hz TV systems from other countries).

 

I think the problem with a digital TV, even if it has a 60 Hz refresh rate, is that it may think that consecutive analog frames are interlaced and tries to de-interlace them, what mixes 0 and 1 frames.

 

By the way, I also looked at Duck Hunt: when you press the trigger you get a black frame, next one that has only a white square on the duck, next back to the normal display. If you have two ducks: black frame, frame with white square for the first duck, frame with white square for the second duck, again frame with white square for the second duck, resume normal display. Interestingly, if I route the TV signal through a VCR, the increased delay is enough to stop the gun from detecting the ducks.

[Shawn]

I got a Rob and Gyromite.

I used a high speed camera (480 fps or 8x the TV rate) to look at the actual output from the TV. I got the same codes as Tursi. The instructions are given one per frame, at 60 fps. There is no black frame after outputing the instruction. The test sequence that flashes the LED on the head is: 00000 000101 1101011 11111.

 

I would think that having the correct timing is pretty important (although I would guess that R.O.B. still works with 50Hz TV systems from other countries).

 

I think the problem with a digital TV, even if it has a 60 Hz refresh rate, is that it may think that consecutive analog frames are interlaced and tries to de-interlace them, what mixes 0 and 1 frames.

 

By the way, I also looked at Duck Hunt: when you press the trigger you get a black frame, next one that has only a white square on the duck, next back to the normal display. If you have two ducks: black frame, frame with white square for the first duck, frame with white square for the second duck, again frame with white square for the second duck, resume normal display. Interestingly, if I route the TV signal through a VCR, the increased delay is enough to stop the gun from detecting the ducks.

 

Well you figure out how to get the zapper working with a modern TV and I'll be your BFF as that is the only reason I still have a CRT kicking around.

[ta0]

Effectively, it's the equivalent to a black screen and a white screen, except rather than flashing a screen I am just flashing an LED light at ROB. I'm definitely interested in whatever you can provide...I'm not so much interested in gaining anything from it other than cracking the code and bringing this technology back to life.

 

 

Well you figure out how to get the zapper working with a modern TV and I'll be your BFF as that is the only reason I still have a CRT kicking around.

 

I looked at the output of an LCD for both Gyromite and Duck Hunter. The output frames are actually the correct ones. My guess is that R.O.B. is not recognizing the codes because there is no "return to zero" : between two consecutive green frames there is no black sync line like there is for the CRT. Perhaps if somebody used a 3D-capable TV with alternating frames at 120 Hz, connected the game to the left eye channel and nothing to the right eye, it might make it recognizable to R.O.B.

Making the zapper work will be more difficult as it seems to be very sensitive to the delay in the loop.

[johannesmutlu]

It would be very interesting to see homebrew game for ROB. To interact with.

But i was also thinking, howabout a new revision of ROB wich uses a microphone instead ,wich recognizes those words from the game stack up and execute those commands once it knows what to do like going up,down left or richt etc,,,

 

And howabout hacking the existing ROB to tab power from the nes rather then using battery's.

 

I hope hyperkin will come with 2 revisions of ROB ,1 wich still uses light sensors while the other will use microphones instead but were both just tab power from the nes instead.

[TheKitty]

Folks, I used your command code research in actually building a simple, low cost R.O.B controller. The codes were spot on, the magic was the timing of the bits.

 

It's all explained in a new guide https://learn.adafruit.com/controlling-a-classic-nintendo-r-o-b-robot-using-circuit-playground-express

 

Hopefully this info will help you and many others in controlling their ROBs without modification or a TV of any type.

 

Long live R.O.B. The Kitty

 

https://blog.adafruit.com/2018/05/25/new-guide-controlling-a-classic-nintendo-r-o-b-robot-circuitplaygroundexpress-circuitpython-nintendoamerica-robots/

Edited May 25, 2018 by TheKitty

[infinitr]

Hello all. Great thread. I've been working on this project as well, off and on over the last few years.

I've experimented with several methods, including an LED flasher similar to that described above (which is awesome btw).

Ultimately, I wanted complete control of the robot, so I designed a completely custom circuit board that interfaces with an Arduino to allow for that. The board interfaces with the existing motors and turn sensors, but bypasses the original optical sensor. However, it also allows you to connect your own buttons, sensors, LEDs, etc to create new methods of interaction. This is a fairly extensive mod, but the board fits in the same location as the original one. I've also upped to voltage slightly by fitting one additional cell.

Perhaps the trickiest part is that these robots are old, and they require maintenance from time to time.

However, the project has been successful and InfinitROB was born.

I've been creating some new experiences, and have even built new accessories for it. The new interactions have been my primary focus.

However, one of the challenges that often gets mentioned is the ability to play Gyromite on a modern monitor or hdtv. You can read about the challenge that this is above. I've come up with a few solutions, one optical like the original and one that circumvents the timing restrictions all together. While the optical is most similar to the original, it is still somewhat prone to error and differences in sensor sensitivity. The latter method uses an NES game pad connected directly to ROB, which can then pass commands both to ROB and to the game, making it able to control Gyromite like the original controls. ROB still operates with a second NES controller connected to a USB adapter. It's a slightly different approach, but it works without the fussiness of refresh rates and such.

I have a ton of information, though I am still working on all this. So far I have built a complete robot with both original and new accessories, as well as a second development board. I've built the complete schematic, circuit board, and all of the code which I am currently cleaning up a bit. I also have the 3D models for accessories including a spinner holder (to place it in alternate positions), gyro holder/button, as well as an arcade button grid that ROB can interact with.

I hope that some of you enjoy this. I've worked hard on it and am pretty proud.

I hope to demo an entirely new ROB experience shortly, which is near completion.

Edited August 19, 2018 by infinitr

[tygerbug]

Neat! Rob and the Zapper were a major reason why the NES succeeded at first. It allowed the system to be sold as a "toy package" and bring up less memories of the video game crash.

[AlbertCX]

Hey everyone, we design and make stuff and we are retrogamers above all, thanks to your posts cracking R.O.B. commands codes and also what the guys at Adafruit did, we can now control R.O.B. without mods so he can play his great games (all two of them) in any modern TV, we gave him a new pair of goggles and a little app, we’re doing final tests and everything looks good so far 

[imstarryeyed]

I think ROB needs to be upgraded, the biggest problem I had with it was it was too noisy and too slow.  I wish I still had my broken one as I would love to upgrade it with new motors and parts for speed.  If the programmer can adjust the speed of movement from regular super slow to a newer fast threshold I think he can be used for more games.  I think making programmable games would be fun.

[Pioneer4x4]

On 9/21/2019 at 7:34 PM, AlbertCX said:

Hey everyone, we design and make stuff and we are retrogamers above all, thanks to your posts cracking R.O.B. commands codes and also what the guys at Adafruit did, we can now control R.O.B. without mods so he can play his great games (all two of them) in any modern TV, we gave him a new pair of goggles and a little app, we’re doing final tests and everything looks good so far 

Very interesting, I am basically never on this anymore, but I am still subscribed to this thread, and love seeing updates.

[Pixelboy]

This thread is very interesting, but although there's a lot of fun technical details found here, there's not a lot of discussion about actual games that could take advantage of ROB.

 

The way I see it, ROB has two main limitations: 1) It doesn't have a large array of moves, and 2) it's quite slow. And there's also the dependence on CRT televisions, but that's a given.

 

Any ROB game worth playing should work around those two limitations, at the game design level. If I were to challenge myself to make a homebrew game for ROB, I would make a game with a well-developed multitasking aspect: Have ROB do something while the player does something else, and the player should be kept busy enough that he doesn't end up constantly waiting for ROB to do his part (and then the player loses patience and just presses ROB's front buttons himself to speed things up). This idea is made harder to implement because of ROB's limited set of actions.

 

As I write this, I am reminded of 2010 - The Graphic Action Game on ColecoVision, where you could tell the HAL 9000 computer to fix a component while you fixed another. Great game. Perhaps ROB could be used in a similar type of game. 

 

 

[astro187]

On 9/21/2019 at 6:34 PM, AlbertCX said:

Hey everyone, we design and make stuff and we are retrogamers above all, thanks to your posts cracking R.O.B. commands codes and also what the guys at Adafruit did, we can now control R.O.B. without mods so he can play his great games (all two of them) in any modern TV, we gave him a new pair of goggles and a little app, we’re doing final tests and everything looks good so far 

I am super interested in this option!  So do the new glasses serve to get the brightness just right, or what?

[AlbertCX]

On 9/24/2019 at 11:06 PM, Pixelboy said:

This thread is very interesting, but although there's a lot of fun technical details found here, there's not a lot of discussion about actual games that could take advantage of ROB.

 

The way I see it, ROB has two main limitations: 1) It doesn't have a large array of moves, and 2) it's quite slow. And there's also the dependence on CRT televisions, but that's a given.

 

Any ROB game worth playing should work around those two limitations, at the game design level. If I were to challenge myself to make a homebrew game for ROB, I would make a game with a well-developed multitasking aspect: Have ROB do something while the player does something else, and the player should be kept busy enough that he doesn't end up constantly waiting for ROB to do his part (and then the player loses patience and just presses ROB's front buttons himself to speed things up). This idea is made harder to implement because of ROB's limited set of actions.

 

As I write this, I am reminded of 2010 - The Graphic Action Game on ColecoVision, where you could tell the HAL 9000 computer to fix a component while you fixed another. Great game. Perhaps ROB could be used in a similar type of game. 

 

 

Yes, that is exactly what we have in mind. To really make ROB useful a game has to keep the player busy while ROB does its thing, for example work cooperatively to solve a problem, the player programs ROB to solve a puzzle and/or send commands on the fly while he or she solves other segment, if they both do it in time correctly then they can move on to the next level.

 

To your points: 

1) "It doesn't have a large array of movements", true but we can take advantage of that by challenging the player to command ROB to solve a puzzle with constraints and limitations, kind of what Stack Up did with blocks. 

2) "it's quite slow" Like you mentioned, we can take the time to have the player busy with a task that is challenging enough where is not boringly easy to complete but not super difficult to the point of frustration. 

 

With these goggles and app we break free of CRT TV dependence but to make all of the above possible there would need to be additional addons for ROB, plus develop the game. We're a small team of hardware and software developers doing this as a labor of love, we'd love to take it to the next level but it will depend if there's enough interest in the community.  

 

On 9/24/2019 at 11:17 PM, astro187 said:

I am super interested in this option!  So do the new glasses serve to get the brightness just right, or what?

The new goggles have the electronics and optics required to send commands to ROB in the same way an old CRT TV did, they connect to the app where there's a screen controller to make it move up, down, right and left plus open/close its arms. With this you can play the original games right off the bat with no modifications to ROB (something I think we can all appreciate since ROB is now an expensive collector's piece), also no need to hack game code and it works on any modern TV. 

 

We have it working now but we're assembling the final version, I'll post a video soon in the meantime here's a shot of ROB wearing the new goggles: 

 

Edited September 26, 2019 by AlbertCX
typo

[Pioneer4x4]

So the hardware glasses actually emit the flashed/code to the ROB, correct?  Are they bluetoothed to the device playing the game or what?  Or do they pickup the screen flashed, and rebroadcast it to the ROB?

[AlbertCX]

7 minutes ago, Pioneer4x4 said:

So the hardware glasses actually emit the flashed/code to the ROB, correct?  Are they bluetoothed to the device playing the game or what?  Or do they pickup the screen flashed, and rebroadcast it to the ROB?

Yes, the goggles emit the flashed/code to ROB (left eye) and they connect Bluetooth to the iPad/iPhone, as of now there's only a screen controller, not a game. To play games you control ROB with the app not the physical NES controller. Like I mentioned above additional hardware would be required to take it to the next level, for instance an inlined device plugged in the NES controller port to "capture" the commands and then send them back to the goggles is very much possible. 

[Pioneer4x4]

7 minutes ago, AlbertCX said:

Yes, the goggles emit the flashed/code to ROB (left eye) and they connect Bluetooth to the iPad/iPhone, as of now there's only a screen controller, not a game. To play games you control ROB with the app not the physical NES controller. Like I mentioned above additional hardware would be required to take it to the next level, for instance an inlined device plugged in the NES controller port to "capture" the commands and then send them back to the goggles is very much possible. 

OK, cool, I figured it would be like that.  Projected price?  Kit, or plans, 3D print file?

Also, Android!!!

Edited September 26, 2019 by Pioneer4x4
ANDROID!!!

[Pioneer4x4]

I wonder if a more passive device would be possible since you worked out how to send the signals, now if there was a way to detect them on a modern display.  It should be possible since you can actually "see" them on playback.

 

[AlbertCX]

We haven't really made commercial plans for this, we will assemble a few engineering prototypes though that I guess if someone wants it we could put it on ebay or something similar. We can make an Android app.... but I'm not sure we can redirect development efforts right now, but again if there's enough demand from the community we're up for anything.

[Pioneer4x4]

Just now, AlbertCX said:

We haven't really made commercial plans for this, we will assemble a few engineering prototypes though that I guess if someone wants it we could put it on ebay or something similar. We can make an Android app.... but I'm not sure we can redirect development efforts right now, but again if there's enough demand from the community we're up for anything.

OK, sounds promising.  I assume the market will be small, but that would depend on the price as well.  

You could do things like make the ROB run from a battery eliminator, sitting up on a shelf with his glasses on, (powered from same source would be cool) 24x7.  Then pull out your phone and have him turn towards guests or something.  

OOOOHHHH, even better, I got it!   "Alexa, tell ROB to open arms"

 

[AlbertCX]

2 minutes ago, Pioneer4x4 said:

"Alexa, tell ROB to open arms"

We're way ahead of you on that one my friend! (you just spoiled the big "one more thing")