My RB5X robot refit, maybe.
For the last month or so I have been tinkering with my RB5X robot. I have the robot stripped down to the chassis and an Activity Board added for some testing of the robot.
I have two methods of controlling the robot, XBee and IR remote control. I use an external terminal program via XBee and of course a hand held IR remote control. So far the results have been promising for further experimentation and robot hardware enhancement. The robot enhancement part could be very costly, I would probably need a 3D printer to make custom brackets and such.
Where in the heck did I get an RB5X robot? Very briefly, back thirty five years ago, I decided to become a distributor for the RB5X robot. As part of the requirements, you had to purchase two robots, so I got one plain RB5X and one with an ARM. And the rest is history.
So far I have found the XBee and IR method to be very good in working with the robot, but I am looking forward too using the AB WX, when Parallax has a good lesson at the Learn site as to how to use the Parallax WX WiFi with the AB WX, and SimpleIDE. I would be replacing the XBee with the WX WiFi, and try controlling the robot via an HTML window?
Their is a continuing debate between using Spin or PropGCC or whatever, going on. So far my experience has been, using PropGCC and the SimpleTools environment to be far superior to using Spin and the OBEX environment. The reasons are very obvious, the SimpleTools library has covered a lot of drivers that do not have to be redesigned and/or recoded to make them work. For prototyping work this is what you need, not spending all your time recoding drivers. Enough said on this subject.
I am now in the process of developing some C code that will look like firmware code for the robot. That means the commands will resemble 0100 in command appearance. As an example when the AB gets a 0100 this could be a command to move the robot forward. After I get some preliminary code, that is working as expected, then I will share the program.
Ray
P.S. I do have a Mitsubishi stationary robot arm that I had purchased back thirty five years ago, it is in the basement collecting dust, but that is another thread.
I have two methods of controlling the robot, XBee and IR remote control. I use an external terminal program via XBee and of course a hand held IR remote control. So far the results have been promising for further experimentation and robot hardware enhancement. The robot enhancement part could be very costly, I would probably need a 3D printer to make custom brackets and such.
Where in the heck did I get an RB5X robot? Very briefly, back thirty five years ago, I decided to become a distributor for the RB5X robot. As part of the requirements, you had to purchase two robots, so I got one plain RB5X and one with an ARM. And the rest is history.
So far I have found the XBee and IR method to be very good in working with the robot, but I am looking forward too using the AB WX, when Parallax has a good lesson at the Learn site as to how to use the Parallax WX WiFi with the AB WX, and SimpleIDE. I would be replacing the XBee with the WX WiFi, and try controlling the robot via an HTML window?
Their is a continuing debate between using Spin or PropGCC or whatever, going on. So far my experience has been, using PropGCC and the SimpleTools environment to be far superior to using Spin and the OBEX environment. The reasons are very obvious, the SimpleTools library has covered a lot of drivers that do not have to be redesigned and/or recoded to make them work. For prototyping work this is what you need, not spending all your time recoding drivers. Enough said on this subject.
I am now in the process of developing some C code that will look like firmware code for the robot. That means the commands will resemble 0100 in command appearance. As an example when the AB gets a 0100 this could be a command to move the robot forward. After I get some preliminary code, that is working as expected, then I will share the program.
Ray
P.S. I do have a Mitsubishi stationary robot arm that I had purchased back thirty five years ago, it is in the basement collecting dust, but that is another thread.
Comments
Back to your RB5X: pictures, where are the pictures? You can't have a bot resurrection without pictures.
I have all of the Heathkit robots. They are cool retro and I love 'em. Great tech for their time, but of course they show their age. Now don't tell nobody, but other than Votrax speech, a Hero Jr does a lot less than an S3. Even an S1!
This might take longer than expected, I suppose I could try using my Raspberry Pi with a camera attached to see if that takes less than 2MB sized pictures. I do not have any of those throw away digital cameras, but then it would not be showing the robot in the detail that the Nikon does.
Ray
http://www.samsung.com/us/explore/family-hub-refrigerator/
I have a Nikon 8800VR (8mp), and it has complete control over image size, quality and format, yours should to. My phones image size cannot be reduced enough for posting on the forum. I have to open the images on the computer in a program called Paint Shop Pro, and re-save it. The program does a better job of .jpeg compression, with no visable difference in quality.
Ray
Ray
Me too, no need to count the pin's on the chip's.
Just when you thought you've seen it all, gives antivirus a whole new meaning for the fridge.
My refrigerator kept beeping today, letting me know the temperature was rising, do to a power outage, not sure how that was done. All I need is to be pestered with text notifications from what used to be a no-brainer.
Where does it end, they should put the TV on the microwave door, better than watching your food go round and round.
The immediate concern that I do have is the robot traction. When I run it on different surface conditions, I get varying results in traction. On a wood surface (floor), it seems to have fairly decent traction, although I noticed some drift. On a carpet surface, like Berber, it starts to show a lot of slippage, and the robot starts to do unpredictable movements. This has to be addressed if I decide to take this further.
I did do an internet search for some replacement wheels, but it seems to be a very limited source. The wheels are 4" dia, and it looks like it takes a 5/16" shaft. I will have to look into this further, but it also looks like it might be a press fit. Not sure how easy it would be to pull the original wheel off, and than have a new wheel stay on. I am not sure what material the tire part of the wheel is, but the material is at least thirty five years old and it looks like it has a concave look to it. When I run my finger on the surface side to side. it feels like edges are ridges while the center has collapsed. Maybe this would run nice on rails.:-)
I will have to look for the other RB5X, and maybe use those wheel assemblies for experimental builds, and then use them as the replacements for the functional unit. The other thing that has to be kept in mind is alignment of charger probes to the charger nest. I forgot to include a picture of that. It is another nice feature of the RB5X, you can eventually program the thing to find the nest and start a charge sequence. I think I am getting sucked into further development.
Ray
Pics look great, thanks Ray!
Ray
Try dipping the cardboard in lacquer, or if it is a very small bracket coat it with nail polish.
I am also working on a custom terminal program, using freebasic as the programming language. On a very basic level the two programs sort of cooperate, but I am having some problems and I do not know on which end the problems are occurring.
The program, rb5x_ab.c works as expected except for the 0003 command, that is not working, as expected, and I do not know why. The teststr.c program works as expected, but I am not sure if that is a correct simulation of the problem. I am assuming that char inBuff[40] = "1000", would be the same kind of data that I would be getting from the serial port, in the rb5x_ab program. What is occurring is that when I send "1000" from the terminal program, the LED turns on, but it does not turn off after one second, it stays on for a couple of minutes if not more. That of course means that the 0003 command is not dealing with the "1000" value correctly, that is a mystery to me.
Trying get two devices to talk to each other, correctly, using serial input/output is becoming more challenging than I expected.
Ray
teststr.c
/* teststr.c */ #include "simpletools.h" int main() // Main function { // Add startup code here. char inBuff[40] = "1000"; long longnum = 0; long exp = 1; int index = 0; print(inBuff); print("\n"); longnum = atoi(inBuff); high(26); pause(longnum); low(26); print(longnum); // while(1) // { // Add main loop code here. // } }rb5x_ab.c
/* rb5x_ab.c January 11, 2017 RB5X firmware */ #include "simpletools.h" #include "simpletext.h" #include "fdserial.h" #include "sirc.h" serial *xbee; /*COGed functions*/ void irrem(); /******************************/ /*DC motor control*/ void goStop(); void goFore(); void goBack(); void goLeft(); void goRite(); /******************************/ int main() { // Add startup code here. /* Rx Tx BAUD */ xbee = fdserial_open(11, 10, 0, 9600); cog_run(irrem,128); // This runs the remote control. char inDec[5]; char inBuff[40]; long inSec = 0; while(1) { // Add main loop code here. readStr(xbee,inBuff,40); if(!strcmp(inBuff,"0001")) high(26); // Diagnostic else if(!strcmp(inBuff,"0002")) low(26); // Diagnostic else if(!strcmp(inBuff,"0003")) { pause(50); readStr(xbee,inDec,5); inSec = atoi(inDec); print("%s",inDec); print("%d",inSec); high(26); pause(inSec); low(26); } else if(!strcmp(inBuff,"0100")) goStop(); // Stop the robot else if(!strcmp(inBuff,"0101")) goFore(); // Continious foreward else if(!strcmp(inBuff,"0102")) goBack(); // Continiuos backward else if(!strcmp(inBuff,"0103")) goLeft(); // Continious left else if(!strcmp(inBuff,"0104")) goRite(); // Continious right else { writeStr(xbee,"Invalid Command\n"); } } } /* COGed functions */ void irrem() { int button = 0; while(1) { button = sirc_button(7); if(button < 100) goStop(); { switch(button) { case 21: // Pwr, Stop robot. goStop(); break; case 16: // Ch+, Foreward. goFore(); break; case 17: // Ch-, Backward. goBack(); break; case 18: // Vol+, Right turn. goRite(); break; case 19: goLeft(); // Vol-, Left turn. break; //default: CRstop(); } } button = 0; } } /******************************/ /*Control of the DC motors.*/ void goStop() { low(15); low(14); low(13); low(12); } void goFore() { high(12); low(13); low(14); high(15); } void goBack() { low(12); high(13); high(14); low(15); } void goLeft() { high(12); low(13); high(14); low(15); } void goRite() { low(12); high(13); low(14); high(15); } /******************************/This my other RB5X, when assembled it would have the ARM inside. As you can see the unit dates itself by having a back plane that would except an S-100 board, and the other ones, I think, take an S-50 board. Now, if were to mount a Propeller chip to an S-100 board, and then...
Ray
I was trying to test out a potential addition of some new commands, that have a timing feature. The wheel assembly has a geared ratio where the robot gets a 1 sec = 1 inch of travel. Now with these new commands I will have more than just on/off of the dc motors. I plan to implement some kind scripted command control, meaning, have a script file that will move the move the robot specified distances, and if I get really ambitious, I can have a command that tells me how far the robot has moved by counting the seconds between on/off of the motors.
I always have thought about implementing a learn feature for a robot. That means, using the remote control, you could walk the robot through a specified route, and have some code that would remember this, and then you could possibly play it back to the robot and it would repeat the route. The implications, teaching the robot a new route like moving away from the charge nest, and then having a home command that it would return the robot to the charge nest. I think I may have to lay down and take a nap again. :-)
Ray
I've always used MS Paint to resize photos I post to the forum. I've been told MS Paint doesn't compress photos as well as other software but I think it works reasonably well.
You mentioned using cardboard for prototyping. Have you tried foam board?
Gordon McComb introduced some of us to expanded PVC (ePVC). I used foam board to make one side of this treaded robot and ePVC for the other side.
ePVC can be cut with a knife. I think it's a lot of fun to use myself. I also used ePVC on my Cleaver robot.
Do the wheels/motors have some sort of encoder? Can you control the robot accurately? I'm wondering if any of the Arlo/Eddie code could be used with your hardware.
Thanks for posting photos. It's really interesting to see the insides of this robot.
I got a timed distance command working, when I put in a 1 sec pause for travel, the robot moved about 7.5 inches. So I think my code is not working as expected. When I use the same code to turn on/off an LED, it seems to be responding correctly, have to love this code debugging.
Ray
This particular code segment, below, is giving me some trouble, it works but not like I expect it to work. What I expect to see occur is the robot to move backwards for one second. But the actual real time movement is probably more like three or four seconds.
Their is probably something that I am missing about how dc motors work, and how it relates to this code segment. The only thing that I can speculate is that the goBack() command is taking up a substantial part of the robot movement, and the one second pause is tacked on to the actual movement time. I guess the next step would be, start reducing the pause time till I actually reach the real time robot movement of one second. I wonder if their is a better way of doing this? I want to get some timed movement commands that are relatively close to having some accuracy.
I also noticed that there is some substantial drift, in the short travel distance. I am doing these tests on my table top, so the surface is not a carpet. I also am wondering now, in my goBack() command, the way the dc motors get activated, may have an influence on the slight drift. I may have to figure out some code where the command starts both dc motors at exactly the same time. To me, lot of questions to be sorted out, I hope I do not have to dig out my old physics books, and start refreshing my brain.
Ray
else if(!strcmp(inBuff,"0004")) // Test actual 1 sec delay. { goBack(); pause(1000); goStop(); }/* rb5x_ab.c January 11, 2017 RB5X firmware */ #include "simpletools.h" #include "simpletext.h" #include "fdserial.h" #include "sirc.h" serial *xbee; /*COGed functions*/ void irrem(); /******************************/ /*DC motor control*/ void goStop(); void goFore(); void goBack(); void goLeft(); void goRite(); /******************************/ int main() { // Add startup code here. /* Rx Tx BAUD */ xbee = fdserial_open(11, 10, 0, 9600); cog_run(irrem,128); // This runs the remote control. char inDec[5]; char inBuff[40]; long inSec = 0; while(1) { // Add main loop code here. readStr(xbee,inBuff,40); if(!strcmp(inBuff,"0001")) high(26); // Diagnostic else if(!strcmp(inBuff,"0002")) low(26); // Diagnostic else if(!strcmp(inBuff,"0003")) { pause(50); readStr(xbee,inDec,11); inSec = atoi(inDec); high(26); pause(inSec); low(26); } else if(!strcmp(inBuff,"0004")) // Test actual 1 sec delay. { goBack(); pause(1000); goStop(); } else if(!strcmp(inBuff,"0100")) goStop(); // Stop the robot else if(!strcmp(inBuff,"0101")) goFore(); // Continious foreward else if(!strcmp(inBuff,"0102")) goBack(); // Continiuos backward else if(!strcmp(inBuff,"0103")) goLeft(); // Continious left else if(!strcmp(inBuff,"0104")) goRite(); // Continious right else if(!strcmp(inBuff,"0201")) // Timed foreward { pause(50); readStr(xbee,inDec ,11); inSec = atoi(inDec); goFore(); pause(inSec); goStop(); } else if(!strcmp(inBuff,"0202")) { pause(50); readStr(xbee,inDec ,11); inSec = atoi(inDec); goBack(); pause(inSec); goStop(); } else { writeStr(xbee,"Invalid Command\n"); } } } /* COGed functions */ void irrem() { int button = 0; while(1) { button = sirc_button(7); if(button < 100) goStop(); { switch(button) { case 21: // Pwr, Stop robot. goStop(); break; case 16: // Ch+, Foreward. goFore(); break; case 17: // Ch-, Backward. goBack(); break; case 18: // Vol+, Right turn. goRite(); break; case 19: goLeft(); // Vol-, Left turn. break; //default: CRstop(); } } button = 0; } } /******************************/ /*Control of the DC motors.*/ void goStop() { low(15); low(14); low(13); low(12); } void goFore() { high(12); low(13); low(14); high(15); } void goBack() { low(12); high(13); high(14); low(15); } void goLeft() { high(12); low(13); high(14); low(15); } void goRite() { low(12); high(13); low(14); high(15); } /******************************/Milliseconds - 100, 150, 200, 250, 300, 1250
Travel Distance in inches 1/4, 1/2, 3/4, 1, 1 1/4, 5
Now, of course these are crude measurements using a tape measure. What I did is use a stationary block, and have the robot back away, then measure the distance, standard stuff. Then for repeatability, I use the forward command to see if it rolled back to the exact spot, it was very close.
In the data chart, it looks like a trend is there, but not the 100 as it would be expected. I thought that the dc motors were an instant start, but it looks like it does have some ramp up time involved. So, does it have some ramp down distance involved? Not sure how to measure, accurately, for that.
I will probably have to add a Ping module, and hope that it has more accurate measurement capabilities than my eyeballing the stuff. Still have to figure out how to get rid of the drift factor, and will that influence the travel distances.
Ray
I will probably have to do some longer, about, maybe five feet, robot travel tests, on the wood floor, not sure how I will setup the experiment though. Not sure how to capture the drift data also. Maybe have two Pings at 90 degree angles, and have them record the distances off of the walls, at the exact same time? This sounds like I would have to create some fancy code to accomplish this, but it could be a way of keeping the robot on a straight course. I was thinking of using a compass to do that, but the robot has steel and aluminum parts which make calibrating the compass very difficult.
Some form of feedback from the wheels?, that would be big challenge for me, not good at creating electronic devices, that even come close to working.
Ray
For feedback you could use a photo-interrupter (https://www.sparkfun.com/products/9299) on the motor or gear box. Very simple circuit and software to count the pulses.
I guess that makes me a purist. I must admit, I do get physically ill when I see someone gut a 1960 Philco Predicta television and install a new color set or computer inside, or gut a Victrola or big console radio to make them into a liquor cabinet. My EYES!
Although I am not much of an antique collector I sympathize with your desire to keep these vintage robots in their original pristine condition. OTOH if the unit was purchased to learn about robotics, electronics, and programming then some changes and additions will need to be made. For this particular robot it looks like a lot of updating could be added without making any changes to the chassis. IOW give new life to an old treasure. Better IMO to make use of it than having it sit collecting dust.
Back about twelve years ago, when I had some free time, I pulled the RB5X out of its shipping box, turned the on/off switch to on, and nothing happened. So, I started to do some diagnostics, first off the battery pack was ~twenty years old which meant that I had to basically take the robot apart to get to the battery pack. After a bit of time I ended up connecting a corded 6V DC supply to the robot, to see if anything would work; yes the prompt appeared on the terminal and I was able to run some sort of Tiny Basic program. The robot internals are still functional.
I tried to find an original equipment battery pack replacement, but none was to be found. So, I ended up getting some small 6V SLA 1Ah batteries and started to experiment from there. As events occurred, I discovered the Parallax BS2 and I got that working with the robot, even had an IR setup so I got too control it via a remote control. Then I discovered the SX stuff, and then the Propeller came on the market, and here I am today.
The one big difference between the RB5X and the other robots that were/are available is the RB5X was designed to be expandable. If you notice in one of the pictures, the robot does have a card cage with expansion slots, plus the outer shell has slots for expansion or allowance for things to be added. So, from a purist stand point, as long as I am not welding on new stuff or completely destroying the innards of the robot, I think I am trying to use it the way it was designed to be used.
The guy that sells the RB5X now, does have a unit that has some kind of antenna inside of the plastic dome area, not sure if it's an XBee setup or some other form of radio signal control. I could probably do something similar, locate the Rx/Tx lines and attach an XBee, and then pick up a prompt on a serial terminal. Now that I think about it maybe that is what I will be doing next. If I recall correctly Tiny Basic was a fairly decent language to work with, at least it worked very good with the RB5X. The robot that I have has a massive 4KB memory expansion board, original equipment, just think what I could do with that.
I am getting some very good ideas here, keep them coming, not sure where this is going now.
Ray
HERO Jr took cartridges (like a game system) and one was BASIC. Limited, but it worked. http://www.the-liberator.net/site-files/robots/heathkit-hero-jr-rt-1/documents/heathkit-hero-jr-basic-rtc-1-8.pdf (thanks Robert!)
Lead acid batteries get sulphated after a few years and poop out, especially if not recharged. I have two BB Battery B3-6 cells from 2004 that are still going strong. Rarely used but topped up about twice a year.
On the front panel of the RB5X it had an EPROM socket, and you could purchase some preprogrammed EPROM's, or you could burn your own. Never got to the point where I had a chance to experiment with that concept.
Ray