limited R/C control of Tamiya gearbox

[Hank Fletcher]

I'm in the process of hacking a cheap remote control and its receiver to use it for controlling a Tamiya double gearbox. I was wondering if anyone had any thoughts about what the best options for direction and steering would be?

The control was only originally designed for forward, stop (centre), and back on the left stick, and left, centre, or right on the right stick. All positions are non-analog (either full on or full off). I suppose if I hack the controller, I could also get two more control options... hmm... actually, what I have is a four-bit output, don't I? So I guess it's actually 16 different options.

It's funny how you think about these things as you write them out! Anyway, still back to the original question, and I guess supposing 16 options (including one of them being the gearbox doing nothing), what would you prefer for motion, steering in particular (turret, etc), but I suppose there could be speed options, too?

 

[Hank Fletcher]

Sorry: for those who don't know, this will be two, independently-powered wheels with an idle caster kind of set-up. If you had a choice of 15 movements, what would they be?

 

[jpanhalt]

That sounds like an AM, 27-MHz cheapo I had 10 years ago. Basically, each stick controlled a motor -- full speed on, off, full-speed reverse. A couple of us built twin-motor, ultralight models. I think they were called Turbo Sports or something. In theory, you could fly with both sticks forward and turn with differential power. Our record flight, with some semblance of control, was maybe 100 yards. In other words, it was damn hard to do.

I mention that episode, because if you have two wheels, each full forward, stop, or reverse, you are going to spend most of the time going like an arrow or spinning.

My advice: buy a used proportional receiver and transmitter. Try the modeler flea markets. My guess is that some guy would be happy to get $25 for a 4 channel TX and RX. I gave all of mine away to kids just starting out. Most of the guys I fly with have done the same with old equipment.

Good luck. If you do try to make the robot with what you have, please post some clips of it in action.

John

 

[3v0]

I agree with John about getting a better rig but.

If you are willing to hack the box you could do most anything you wanted with a pair of uC to encode/decode the stream.

 

[nickelflippr]

One suggestion might be to decode the receiver input with a microcontroller, then redirect your outputs to mimic tank control. Meaning the right and left sticks would control their respective motors forward, off, back. That way just seems more intuitive to me.

With those motors, speed control may be more hassle/cost than its worth. The motors need to be geared fairly low to get the platform moving.

 

[Pommie]

With 4 bits you can have 2 bits per side which will give you 2 forward speeds and 1 reverse per side (+stop).

Mike.

 

[Torben]

With 4 bits you can have 2 bits per side which will give you 2 forward speeds and 1 reverse per side (+stop).

Mike.

I know I'm missing something here, but it seems to me that with 4 bits you have 16 options: stop and reverse plus 6 speeds per side. If you split the 4 bits into 2 2-bit chunks you only get stop and reverse plus 2 speeds per side.

Mind you, I do have a couple of beers in me.


Torben

 

[Pommie]

I know I'm missing something here, but it seems to me that with 4 bits you have 16 options: stop and reverse plus 6 speeds per side. If you split the 4 bits into 2 2-bit chunks you only get stop and reverse plus 2 speeds per side.

Mind you, I do have a couple of beers in me.


Torben

You need to turn. Fast forward right and slow forward left gives a fast moving turn to the left. The different combinations give you different speed and turn rates.

Edit, I see the confusion now. Stop, reverse and 6 speeds per side requires 8 combinations which is 3 bits per side. You can't split 16 combinations into 2 lots of 8. You can do 8 combinations plus 2 combinations.

Mike.

 

[Hank Fletcher]

Edit, I see the confusion now. Stop, reverse and 6 speeds per side requires 8 combinations which is 3 bits per side. You can't split 16 combinations into 2 lots of 8. You can do 8 combinations plus 2 combinations.

I think 3v0 clued into what I'm thinking about doing, although I'll probably just use one mcu on the receiver side to collect the 4-bits (so no streaming for the first crack at this, although that'd definitely give me more options!). Presuming the 4-bits can be processed, that gives 15 movement options other than full-stop (0), with the bits being interpreted for whatever other options are most desirable.

Do we all agree, though, that even given the extra resources and more often than not redundancy, that we'd prefer to have symmetrical options with respect to both wheels? I just remember being really irritated as a kid with those R/C cars that could turn left or right when moving forward, but only turned in one direction when backing up. If real life were like that, I'd never be able to parallel park!

 

[Hank Fletcher]

Motion options (and what each wheel is doing):
0 - stop
1 - forward, top speed (fast left, fast right)
2 - reverse, top speed (fast reverse left, fast reverse right)
3 - ccw fast (fast reverse left, fast right)
4 - cw fast (fast left, fast reverse right)
5 - foward, slow (slow left, slow right)
6 - reverse, slow (slow reverse left, slow reverse right)
7 - ccw slow (slow reverse left, slow right)
8 - cw slow (slow left, slow reverse right)
9 - right turn (slow left)
10 - left turn (slow right)
11 - right bend (fast left, slow right)
12 - left bend (slow left, fast right)
13 - right reverse bend (fast reverse left, slow reverse right)
14 - left reverse bend (slow reverse left, fast reverse right)
15 - fire!

Opinions?

 

[3v0]

How are you going to retrofit the joysticks?

 

[Hank Fletcher]

How are you going to retrofit the joysticks?

I was thinking of hooking up the controller to my parallel port, so presuming I can handle the cpu programming, the options for controlling the robot would be the usual ones associated with a computer: keyboard and mouse (hmm... maybe a game controller, too?...)

Old school!
**broken link removed**

 

[3v0]

I was thinking of hooking up the controller to my parallel port, so presuming I can handle the cpu programming, the options for controlling the robot would be the usual ones associated with a computer: keyboard and mouse (hmm... maybe a game controller, too?...)

It looks like you are going to have processing on both ends. You may as well use one or more channels to send digital data that you can decode.

About the only thing you are missing is data definition / protocol.

 

[Torben]

Edit, I see the confusion now. Stop, reverse and 6 speeds per side requires 8 combinations which is 3 bits per side. <b>You can't split 16 combinations into 2 lots of 8.</b> You can do 8 combinations plus 2 combinations.

Mike.

That's what I mean by "splitting the 4 bits into 2 per side". You then have 2^2 = 4 discrete options per side, which as you say is quite limiting.

If you instead use your 4 bits together as one 4-bit value and decode it on the bot then you have 2^4 = 16 different options. Use 8 for one side and 8 for the other.

Hank wrote out one list of options. My first idea was slightly different:

0000 Left Stop
0001 Left 1
0010 Left 2
0011 Left 3
0100 Left 4
0101 Left 5
0110 Left 6
0111 Left Reverse
1000 Right Stop
1001 Right 1
1010 Right 2
1011 Right 3
1100 Right 4
1101 Right 5
1110 Right 6
1111 Right Reverse

. . .but generally the same kind of idea.



Torben

 

[nickelflippr]

3VO said:
It looks like you are going to have processing on both ends. You may as well use one or more channels to send digital data that you can decode.

Seems to be getting a bit convoluted. With one of those cheap Vex controllers that have been talked about, you hold the processing to the receiving end. I am sure that having computer control could have some advantages tho, like maybe not having to recharge transmitter batteries?

 

[Hank Fletcher]

0000 Left Stop
0001 Left 1
0010 Left 2
0011 Left 3
0100 Left 4
0101 Left 5
0110 Left 6
0111 Left Reverse
1000 Right Stop
1001 Right 1
1010 Right 2
1011 Right 3
1100 Right 4
1101 Right 5
1110 Right 6
1111 Right Reverse

Ah! So you're saying it would be redundant to have a code for moving both wheels in the same direction. Instead, the cpu program should interpret a keyboard command for "forward" or "backwards" and quickly send alternating left-right code to the robot. Essentially a 50%, alternating PWM signal message sent through the parallel port and over the transmitter would be required for "straight" motion. 100Hz would probably be fast enough, but if part of the system hangs (most suspect would be my Windows 2000 OS), there could be unexpected, chaotic results. I love it!

 

[Torben]

Ah! So you're saying it would be redundant to have a code for moving both wheels in the same direction. Instead, the cpu program should interpret a keyboard command for "forward" or "backwards" and quickly send alternating left-right code to the robot. Essentially a 50%, alternating PWM signal message sent through the parallel port and over the transmitter would be required for "straight" motion. 100Hz would probably be fast enough, but if part of the system hangs (most suspect would be my Windows 2000 OS), there could be unexpected, chaotic results. I love it!

Actually I was mostly just trying to see what Mike is saying about the limit on the number of discrete values per side. I know Mike's pretty darn smart so I wanted to get what he was getting at and for some reason it didn't sink in for me until this post of yours.

Mike, I know what you're saying now. Makes perfect sense.

Hank, to be honest almost all of my bot programming has been in pseudo-simulators (like droidbattles) so I quite liked your value map, since it would fit nicely with the droidbattles assembly language. Although the possibility of doing the PWM control you outlined would be fun (especially if control were lost as you mentioned.)

I've got some work to attend to then I'll think about this some more.


Torben

 

[3v0]

Seems to be getting a bit convoluted. With one of those cheap Vex controllers that have been talked about, you hold the processing to the receiving end. I am sure that having computer control could have some advantages tho, like maybe not having to recharge transmitter batteries?

Keep in mind that my original suggestion was to get a better RC rig. All I am suggesting is that one could use the original simple RC setup as a channel to send data between two processors. On the reciever end you can use a PIC to decode the data stream. After that standard h-bridge PWM etc for as many items as you need to control.

I have no idea regarding how fast data could be transmitted.

 

[Hank Fletcher]

I have no idea regarding how fast data could be transmitted.

There seems to be only one way to find out, and that's to do it! I'm going to have a crack at it, first a simple non-stream method. If that works well and consistently, I might try bumping up my options to - dare I dream - a two-bit packet!