DIY custom 2.4ghz RC radio system for robotics... - RobotShop Forum

Putting robotics at your service™

Free shipping on orders over $75

DIY custom 2.4ghz RC radio system for robotics...

Print view Share :
Previous topicNext topic

Page 4 of 20 [ 289 posts ]

1, 2, 3, 4, 5, 6, 7 ... 20
Guru ( offline )
Posts: 2158
Posted: 2008-10-21 14:38 
zenta wrote:
kurte wrote:
...
What I liked about this approach was that you did not having to encode the data in a PWM signal and then having to receive multiple channells of PWM at the other end.

Good point Kurt, especially handling all the pwm at the end (receiver) take very much time. What about a little microcontroller taking care of all pwm readings with an interrupt code, so that the main BAP28 on BB2 just can send a pulse (IRQ) to the microcontroller when it needs the pwm data. And then the microcontroller can send the pwm data via a serout command to the BAP28? Just an idea :roll:

Not really that familiar with the micro on the BAP but does it have hardware capture on any of the port pins? If it does and we are only talking about capturing a single channel to decode the keypad then could one of the folks familliar with the cpu architecture and doing BAP interrupts write a short routine to simple capture pulses on that channel and put the results in a variable? It seems like that would go a long way to minimizing the impact on the top level program loop.


User avatar
Guru ( offline )
Posts: 9256
Posted: 2008-10-21 15:02 
kurte wrote:
If I have time in the next day or so, I will hack up some preliminary code to read the keypad.


Thanks in advance!

Here is a proposal for the Atom Pro pinout. The 4 x 8 keypad interface sure does gobble the I/O pins. If we ditch the speaker we can actually scan 3 joysticks! 8) I like having the speaker though.

X = Horizontal, Y = Vertical

P0 = Keypad A
P1 = Keypad B
P2 = Keypad C
P3 = Keypad D
P4 = Keypad 1
P5 = Keypad 2
P6 = Keypad 3
P7 = Keypad 4
P8 = PPM out
P9 = Speaker
P10 = LCD out
P11 = Spare
P12 = Keypad 5
P13 = Keypad 6
P14 = Keypad 7
P15 = Keypad 8
P16 = Joystick 2 (right) Y
P17 = Joystick 2 (right) X
P18 = Joystick 1 (left) Y
P19 = Joystick 1 (left) X

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...


Guru ( offline )
Posts: 2158
Posted: 2008-10-21 15:24 
what no inputs for the 3-axis accelerometer module :?:


User avatar
Guru ( offline )
Posts: 9256
Posted: 2008-10-21 15:38 
EddieB wrote:
what no inputs for the 3-axis accelerometer module :?:


It'll have to wait for Rev 2. ;)

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...


User avatar
Guru ( offline )
Posts: 1138
Posted: 2008-10-21 16:07 
Hi Jim,

Robot Dude wrote:
P0 = Keypad A
P1 = Keypad B
P2 = Keypad C
P3 = Keypad D
P4 = Keypad 1
P5 = Keypad 2
P6 = Keypad 3
P7 = Keypad 4
P8 = PPM out
P9 = Speaker
P10 = LCD out
P11 = Spare
P12 = Keypad 5
P13 = Keypad 6
P14 = Keypad 7
P15 = Keypad 8
P16 = Joystick 2 (right) Y
P17 = Joystick 2 (right) X
P18 = Joystick 1 (left) Y
P19 = Joystick 1 (left) X


I don't know why you placed every single button on a single pin but usally such keypaths will have a multiplexer so you will only need 4 inputs (4^2=16). You can simply read a nib instead of a single pin (this is a different command).

Xan


Guru ( offline )
Posts: 2158
Posted: 2008-10-21 16:17 
Xan wrote:
I don't know why you placed every single button on a single pin but usally such keypaths will have a multiplexer so you will only need 4 inputs (4^2=16). You can simply read a nib instead of a single pin (this is a different command).
Xan

Um, he has two (2) 4x4 keypads , each having 4 rows and 4 columns for a total of 32 buttons. To read them he needs 4 x 8, that is 4 rows and 8 columns... which is exactly what he has... A-D, 1-8 which uses 12 of the 16 I/O lines on a BAP. ;)


User avatar
Guru ( offline )
Posts: 9256
Posted: 2008-10-21 16:58 
I should have labeled them differently to avoid confusion. BTW this proposal is admittedly overkill in the keys department. The goal was directed to 16 keys for behaviour/device control, and the second keypad for arm control.

Code:
R=Row
C=Column
P0 = Keypad R1
P1 = Keypad R2
P2 = Keypad R3
P3 = Keypad R4
P4 = Keypad C1
P5 = Keypad C2
P6 = Keypad C3
P7 = Keypad C4
P8 = PPM out
P9 = Speaker
P10 = LCD out
P11 = Spare
P12 = Keypad C5
P13 = Keypad C6
P14 = Keypad C7
P15 = Keypad C8
P16 = Joystick 2 (right) Y
P17 = Joystick 2 (right) X
P18 = Joystick 1 (left) Y
P19 = Joystick 1 (left) X


If we want we can go a little more conservative and just do one keypad. One key could toggle from basic control to arm control. If so it would be more like this.

Code:
R=Row
C=Column
P0 = Spare analog input (battery check)
P1 = Spare analog input
P2 = Joystick 3 (optional) Y
P3 = Joystick 3 (optional) X
P4 = Keypad R1
P5 = Keypad R2
P6 = Keypad R3
P7 = Keypad R4
P8 = PPM out
P9 = Speaker
P10 = LCD out
P11 = Spare
P12 = Keypad C1
P13 = Keypad C2
P14 = Keypad C3
P15 = Keypad C4
P16 = Joystick 2 (right) Y
P17 = Joystick 2 (right) X
P18 = Joystick 1 (left) Y
P19 = Joystick 1 (left) X


This frees up 4 more I/O pins. 8)

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...


User avatar
Guru ( offline )
Posts: 4942
Posted: 2008-10-21 20:50 
EddieB wrote:
Zenta wrote:
Good point Kurt, especially handling all the pwm at the end (receiver) take very much time. What about a little microcontroller taking care of all pwm readings with an interrupt code, so that the main BAP28 on BB2 just can send a pulse (IRQ) to the microcontroller when it needs the pwm data. And then the microcontroller can send the pwm data via a serout command to the BAP28? Just an idea :roll:

Not really that familiar with the micro on the BAP but does it have hardware capture on any of the port pins? If it does and we are only talking about capturing a single channel to decode the keypad then could one of the folks familliar with the cpu architecture and doing BAP interrupts write a short routine to simple capture pulses on that channel and put the results in a variable? It seems like that would go a long way to minimizing the impact on the top level program loop.

On the BAP we could use TimerW to capture the input timing of 4 pins FTIOA-FTIOD (P9-P12 on the BAP). However for this RC receiver we will probably be receiving at least 6 channels of PWM (2 for each joystick and I think Jim was thinking 2 for the keyboard states) as to leave enough difference in the values to receiving the values less error prone. My current Rover code (when the rover is in one piece) was using hardware interrupts (WKPxxx)for pins P0-p5, which was working reasonably well, but the large number of interrupts caused the timings of the bit bang functions like serout to not work very well. The basic version that is used on my Phoenix uses basic (pulsein) to get these values, which as it does not use interrupts implies that the serouts work well. However nothing else happens while the pulsein is waiting so your main code loop may take a lot longer to process and as Zenta mentioned and as such his phoenix may not walk as quickly as Xans.

Once the updated version of XAN's code is up and I get a change to reintegrate my changes I will see how fast I can make it. I may try the approach I used on the Rover and maybe simply disable the Interrupt code while the serouts are being processed... But that is more for a different thread...

Kurt


Rookie ( offline )
Posts: 47
Posted: 2008-10-21 23:02 
Two keypads look cool but one is all you need, unless you have two people punching info at the same time! The extra four pins you save could be used as a simple switch joystick, like a HAT. You could incorporate a rotational encoder instead of the HAT.


Guru ( offline )
Posts: 2158
Posted: 2008-10-22 00:21 
why would you need to read the joystick channels? one or two channels to read the keypad and perhaps another control like russ suggested a wheel or hat or a slider even. heck it would be easy enough to do a 3-axis hat if you encode the z-axis switch in bit 7 and use bits 0-6 for the 8 possible positions.


User avatar
Guru ( offline )
Posts: 4942
Posted: 2008-10-22 00:47 
EddieB wrote:
why would you need to read the joystick channels? one or two channels to read the keypad and perhaps another control like russ suggested a wheel or hat or a slider even. heck it would be easy enough to do a 3-axis hat if you encode the z-axis switch in bit 7 and use bits 0-6 for the 8 possible positions.

Jim, sorry if this is off topic, also sorry if I have not explained myself very well. I think we are talking about the two different halves of the problem. In the prototype box, this should be sort-of easy. We read the values in from the two gimbals(joysticks) in the controller, this will generate the first 4 pwm signals that we send out on the airmod transmitter. We then read the state of the buttons on the keypad(s) and use it to generate a 5th and possibly 6th channel to transmit. I believe Jim proposed some values in the other thread. Something like:
Code:
NOP  1100uS
  0  1150uS
  1  1200uS
  2  1250uS
  3  1300uS
  4  1350uS
  5  1400uS
  6  1450uS
  7  1500uS
  8  1550uS
  9  1600uS
 10  1650uS
 11  1700uS
 12  1750uS
 13  1800uS
 14  1850uS
 15  1900uS


Now we get to the other part (hopefully in my Hex or Rover) and that is the receiver. It is my belief that the receiver will have 6 or more channels, where each channel will plug into different IO pins on the robots BAP board. We will then want to decode this information in order to control the robot. This is the part I was talking about earlier. You can spend a lot of time waiting in the Pulsein commands, especially if you don't do them in the right order (another topic).

Kurt


Guru ( offline )
Posts: 2158
Posted: 2008-10-22 01:01 
Oh I was thinking the TX part of this was straight forward enough once you got a routine to generate the PPM signal with enough resolution to be useful. I thought Jim had already done the basics of that.

On the RX in my head I am thinking ROV so why would you need to decode the first 2 axis anyway as they are just speed and turn applied to an rc speed controller like the sabertooth things. However if I step back from my own project I can see that if you were looking to drive a gait sequencer or state machine for a legged robot then yes you would potentially need to decode all 6 or 7 PWM channels as delivered by the receiver. Now you may want to poke around on rcgroups because I think I saw some information about people opening/hacking the spektrum receiver and intercepting the PPM stream to access it directly rather than decode the individual servo outputs. If I get time around lunch I'll see if I can re-trace my steps and find the information again. I also think I saw a project re-creating a PPM signal in hardware from the individual PWM servo signals... I want to say it was for something called a microkopter or something like that... so I'll see if I can find that information too.


User avatar
Guru ( offline )
Posts: 4942
Posted: 2008-10-22 11:50 
Hi Eddie,

As you said for many you may simply hook up the first joystick output directly to your speed controller. That is what I had when I first built my rover. But later I wanted some control over it. For example maybe if I press a button, the RC controller is now controlled by the software on the Atom. Pressing another button, maybe I want to use the joystick to now controll the gripper on the front of the rover or the pan and tilt on top...
Would be great to find a way to intercept the stuff before it seperate channels on the receiver...

Now back on subject:

This morning I started hacking the first round of the keypad. I have one of these:http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=152063

I need to continue debugging my code as some of the BAP code is not debugging the way I would expect:
I tried using DIRA, DIRB (latter DIRL) to setup the input/output bits the way I wanted: the P0-P3 output, P4-P7 input, and then tried using OutA, InB to try to set and read 4 bits at a time and it is not getting the results I expect. Will debug more later. But now the electricians have arrived...

Kurt


User avatar
Guru ( offline )
Posts: 9256
Posted: 2008-10-23 12:35 
Here's a little program update. When I asked for a formula for converting the joystick values to the servo output values I mistakenly used 900us to 2100uS. This caused a problem in the receiver resulting on a non-symmetrical response. I needed to change it to 1000uS to 2000uS. To avoid floating math I multiplied by 42, subtracted 6500 then divided the result by 10. Beth created a spreadsheet formula so we could alter the two values to get the best result. So now the LCD displays the correct values and the joysticks now center at 1500 and have a symmetrical throw. Next I will throw a Bot Board II and Atom Pro on the receiver side and start writing a simple routine to measure the keypad channels to turn some LED's on and off.

Code:
cha1 var word
cha2 var word
cha3 var word
cha4 var word
cha5 var word
cha6 var word
cha7 var word
a_key var bit
b_key var bit
c_key var bit

sound 9, [100\880, 100\988, 100\1046, 100\1175]

serout 8,N9600,[12, 14]

low 15

start:

adin 16, cha1 ;right vertical
adin 17, cha2 ;right horizontal
adin 18, cha3 ;left vertical
adin 19, cha4 ;left horizontal

;convert joystick values 392 - 692 to servo values 1000uS - 2000uS
cha1=(((cha1*42)-6500)/10)
cha2=(((cha2*42)-6500)/10)
cha3=(((cha3*42)-6500)/10)
cha4=(((cha4*42)-6500)/10)
cha5=1500
cha6=1500
cha7=1500

serout 8,N9600,[16, 64, dec cha3, 16, 76, dec cha1, 16, 80, dec cha4, 16, 92, dec cha2]
;serout 8,N2400,["hello world     "]
;serout S_OUT,i57600,[dec5 cha1\5," ",dec5 cha2\5," ",dec5 cha3\5," ",dec5 cha4\5," ",13]

makepulses:
pulsout 15,800
pauseus ((cha1*2)-800)
pulsout 15,800
pauseus ((cha2*2)-800)
pulsout 15,800
pauseus ((cha3*2)-800)
pulsout 15,800
pauseus ((cha4*2)-800)
pulsout 15,800
pauseus ((cha5*2)-800)
pulsout 15,800
pauseus ((cha6*2)-800)
pulsout 15,800
pauseus ((cha7*2)-800)
pulsout 15,800
goto start

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...


User avatar
Guru ( offline )
Posts: 9256
Posted: 2008-10-23 15:13 
I decided to lay down some specifics pertaining to the joystick configuration. In the RC world there is Mode 1 popular in Europe and Mode 2 popular in the states. In mode 2 the left joysticks vertical axis is used for throttle and does not return to center if released. The right gimbal has spring returns on both axis. In robotics a single stick used for motion control would need to return to center (stop the robot) if released. So we use the right stick for motion control. The left stick lends itself to pan and tilt operation. I sometimes remove the horizontal centering springs on the left stick as well.

I chose to scan the gimbals in this order.

Ch1 - right vertical, spring return, Throttle (elevator)
Ch2 - right horizontal, spring return, Steering (ailerons)
Ch3 - left vertical, no spring return, Tilt (throttle)
Ch4 - left horizontal, spring return, Pan (rudder)

Also here is how the sticks are working now.

Code:
         1958uS                 1962uS
           |                      |
           |                      |
1009uS ----o----2008uS  1004uS----o----2017uS
           |                      |
           |                      |
         1084uS                 1051uS

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...


1, 2, 3, 4, 5, 6, 7 ... 20

All times are UTC - 5 hours [ DST ]. It is currently 2018-04-24 17:10