Additions:
Oldest known version of this page was edited on 2007-07-20 00:06:31 by BhMike []
Page view:
Pic Relay Controller (PRC)
Posted by the moth:
The experimental relay controller is a joint attempt between Robowars , Mothbots and other interested partys to produce a combat ready - cheap "entry level" motor controller with a successfully failsafe system . Based on a "picaxe" micro controller and using very few components the ultimate cost of this simple controller is hoped to be about $30.oo . The Pic-Relay-Controller (PRC) plugs directly into the radio receivers servo outputs and can be configured to supply power direct to the receiver .
Outputs are provided for the main drive relays ( 2 Channel ) and weapon drive relays ( 1 Channel ) and "channel mixing" is done in the software to greatly reduce set-up problems . Separate outputs are present for a power led , a "fail safe" led and mimic led's from the relay drives . Most of the components on the board are optional allowing a minimalist version to be built very cheaply . Designed to run from a wide range of voltages , the PRC is hoped to provide a simple and cheap solution to both new and old entrants . Options like opto-isolation , simple proportional control and separate power supplies are being considered for the "extended version" but this wont be available for some time yet.
Parts
The present parts list for the PRC is :
1 x picaxe 18x processor ( must be 18x)
1 x 7805 5v power regulator
1 x 220uf capacitor
1 x .1uf capacitor
1 x uln2003 driver chip
1 x led for power indicator
1 x led for failsafe indicator
2 x 220ohm resistors ( for leds )
suitable connection leads to the radio receiver
screw connectors for the relay outputs
header pin connector for the "in-circut" programming lead
Optional but recommended :
6 x leds to miminc relay drives (trouble shooting)
6 x 220 ohm resistors for leds
The PRC is presently built on "vero board" and a pre made board will not be available for some months
Photos and a wiring diagram are at my website
http://www.allsuburbs.com/robots/mothbots/relaycontrol/relay.html∞
Code
This is the latest code that I have seen, although Rick last used version 4.3 at Robowars '06, and a version III board/schematic at Robowars '07. He has said that the any version past 4.0 appears to be stable, but as always you must be the judge of this as no warrenty is implied or given. This code was posted by Spockie-Tech in the forum in January '06
Here is the current version of the PRC code..
Note that this is presently set for use of opto-couplers on the Servo Inputs, which means it times an active *low* pulse (since Opto's invert the signal).
To use it without Opto's, change the second parameter on each of the pulsin caommands to a "1" (look for a 1 or high input). eg. pulsin 0,1,chan1 'get Radio Control Channel 1 pulsewidth.
Our present idea is to use small logic-level relays on the outputs which then switch the coils of the larger motor relays, and use a Receiver battery to completely isolate the PicAxe and Receiver from the Robots main power batteries which are subject to the big spikes when two relays, 2 or 4 motors start, and a 100+ amp load spike hits the power supply.
The next event should see how well this idea works.. Wink
Also, note the quadrant diagram comments (the messed up formatting bit - it works in a monospaced font), doesnt correspond to the code exactly, since Rick (Moth) changed the side-stick movements to only drive 1 motor at a time to make the side steering less twitchy..
code:
;
; PRC - Pic Relay Controller - v4.0x
; Copyright Nov 2004 Brett Paulin
; Oct04 - Hysteresis Bug Fix by Ajax
; Dec04 - Failsafe Trigger Points re-tuned
; May05 - Pulse-in inverted for Opto-isolaters
; May05 - Quadrant control adjusted to reduce main turn rate
; May05 - Channel_3 mask bug fixed by Moth
; written for PicAxe 18X micro
; www.robowars.org
;
setfreq m8
;-General Definitions
symbol failsafe_trig = 3
symbol failsafe_max = 12
;-RC Channel Definitions
symbol fail_low =60 ; (old 60) failsafe below here
symbol fail_high =240 ; (old 240) failsafe above here
symbol low_on =120 ; (old 120) low activate point
symbol low_off =135 ; (old 135) low deactivate point
symbol high_off =175 ; (old 175) high deactivate point
symbol high_on =180 ; (old 180) high acticate point
;
Memory Register Usage Definitions
symbol failsafe_float=b0 ; current block error rate
symbol ch1mode=b1 ; channel 1 mode
symbol ch2mode=b2 ; channel 2 mode
symbol ch3mode=b3 ; channel 3 mode
symbol outpins=b4 ; output pins data
symbol start_flash=b5 ; startup led flash
symbol chan1 = w3 ; b7 + b6 - channel 1 timing word value
symbol chan2 = w4 ; b9 + b8 - channel 2 timing word value
symbol chan3 = w5 ; b10 + b11 - channel 3 timing word value
;
I/O Pin Definitions
symbol ch1_fwd = %00000001 ; binary bit patterns to mix in
symbol ch1_mid = %00000000 ; to output pins for relay/led
symbol ch1_bck = %00000010 ; activation / deactivation
symbol ch2_fwd = %00000100
symbol ch2_mid = %00000000
symbol ch2_bck = %00001000
symbol ch3_fwd = %00100000
symbol ch3_mid = %00000000
symbol ch3_bck = %01000000
;- Mixing Mask Definitions
symbol ch1_mask = %11111100 ; which bits should be masked off
symbol ch2_mask = %11110011 ; for logical OR mixing process
symbol ch12_mask = %11110000
symbol ch3_mask = %10011111 ; Fixed potential bug here
symbol failsafeout = %00010000
failsafe_float = 11
flash_led: ; Flash the fail safe Led at startup
for start_flash = 1 to 20
let pins = failsafeout
pause 400
let pins = ch1_mid
pause 400
next start_flash
;
main_loop:
setfreq m4 ; Reduce cpu speed as command has probs
pulsin 0,0,chan1 'get Radio Control Channel 1 pulsewidth
pulsin 1,0,chan2 'get Radio Control Channel 2 pulsewidth
pulsin 2,0,chan3 'get Radio Control Channel 3 pulsewidth
setfreq m8 ; Double cpu speed for rest of prog
if chan1 < fail_low or chan1 > fail_high then goto failsafe
if chan2 < fail_low or chan2 > fail_high then goto failsafe
if chan3 < fail_low or chan3 > fail_high then goto failsafe
failsafe_float = failsafe_float - 1 MIN 1
if failsafe_float > failsafe_trig then goto shutdown
if failsafe_float < failsafe_trig then goto chan1_test
goto shutdown
;
chan1_test:
if chan1 < low_on then chan1_low
if chan1 > low_off and chan1 < high_off then chan1_mid
if chan1 > high_on then chan1_high
if chan1 > high_off and ch1mode = 0 then chan1_mid
if chan1 > low_off and ch1mode = 255 then chan1_mid
goto chan2_test
chan1_low:
ch1mode=0 ; channel 1 is low (full back)
goto chan2_test
chan1_mid:
ch1mode=127 ; channel 1 is centered
goto chan2_test
chan1_high:
ch1mode=255 ; channel 1 is high (full forward)
goto chan2_test
;
chan2_test:
if chan2 < low_on then chan2_low
if chan2 > low_off and chan2 < high_off then chan2_mid
if chan2 > high_on then chan2_high
if chan2 > high_off and ch2mode = 0 then chan3_mid
if chan2 > low_off and ch2mode = 255 then chan3_mid
goto chan3_test
chan2_low:
ch2mode=0 ; channel 2 is low (full back)
goto chan3_test
chan2_mid:
ch2mode=127 ; channel 2 is centered
goto chan3_test
chan2_high:
ch2mode=255 ; channel 2 is high (full forward)
goto chan3_test
;
chan3_test:
if chan3 < low_on then chan3_low
if chan3 > low_off and chan3 < high_off then chan3_mid
if chan3 > high_on then chan3_high
if chan3 > high_off and ch3mode = ch3_bck then chan3_mid
if chan3 > low_off and ch3mode = ch3_fwd then chan3_mid
goto mixing
chan3_low:
ch3mode=ch3_bck
goto mixing
chan3_mid:
ch3mode=ch3_mid
goto mixing
chan3_high:
ch3mode=ch3_fwd
;
mixing:
outpins = pins ; get current pins state
outpins = outpins & ch12_mask ; mask off current ch 1 + 2 output state
if ch1mode=0 and ch2mode=127 then bkwd ; check channel 1 and 2 modes
if ch1mode=127 and ch2mode=127 then stp ; and determine 9-point quadrant
if ch1mode=255 and ch2mode=127 then fwd ; position
if ch1mode=0 and ch2mode=255 then bkwd_right
if ch1mode=127 and ch2mode=255 then right
if ch1mode=255 and ch2mode=255 then fwd_right
if ch1mode=0 and ch2mode=0 then bkwd_left
if ch1mode=127 and ch2mode=0 then left
if ch1mode=255 and ch2mode=0 then fwd_left
;
fwd: ; mix in appropriate ouput state
outpins = outpins | ch1_fwd
outpins = outpins | ch2_fwd
goto mix_done
outpins = outpins | ch1_fwd
outpins = outpins | ch2_mid
goto mix_done
; 1F & 2F
fwd_left: ; Fwdoutpins = outpins | ch1_mid ;1M & 2F 1F & 2M
outpins = outpins | ch2_fwd ;Fwd_left | Fwd_right
goto mix_done ; \ | /
; \ | /
stp: ;1B & 2F \|/ 1F & 2Boutpins = outpins | ch1_mid ;left - - - | - - - right
outpins = outpins | ch2_mid ; /|\
goto mix_done ; / | \
;1B & 2M / | \ 1M & 2B
;bkwd_left | bkwd_right
right: ;;bkwd_left | bkwd_right
outpins = outpins | ch1_fwd ; bkwd
outpins = outpins | ch2_mid ; 1B & 2B
goto mix_done ;
;
left: ;"full rate" turns removed fromoutpins = outpins | ch1_mid ; left and right quadrents to
outpins = outpins | ch2_fwd ; improve driveability
goto mix_done
outpins = outpins | ch1_bck
outpins = outpins | ch2_bck
goto mix_done
bkwd_right:
outpins = outpins | ch1_fwd
outpins = outpins | ch2_bck
goto mix_done
bkwd_left:
outpins = outpins | ch1_bck
outpins = outpins | ch2_fwd
mix_done:
mix_aux:
outpins = outpins & ch3_mask ; mix in current weapon channel state
outpins = outpins | ch3mode
let pins = outpins
goto main_loop ; then loop around and do it all again
;
;
;What do if a failsafe occurs
failsafe:
failsafe_float = failsafe_float + 1 MAX failsafe_max
if failsafe_float > failsafe_trig then goto shutdown
goto main_loop
shutdown:
let pins = failsafeout
goto main_loop
All information has come from either the forum http://www.robowars.org/forum/viewtopic.php?t=479∞,
or Rick's web page http://www.allsuburbs.com/robots/mothbots/relaycontrol/relay.html∞
Forum highlights
Posed by the moth:
We are considering some modifications to allow the micro to drive smaller relays first that then activate the "power" relays (any reasonable value you like) and power the pic , receiver and the low power relays from a receiver battery pack to reduce radio problems . I have found that the micro generates some radio noise - so it is best to keep it away from the receiver . Our present set-up uses a common ground to the main relays and the main relays do create some spikes that may be causing occasional glitches in the micro . I have fitted some large filter caps on the 12v power rail at the PRC but this hasn't fixed the problem . Fully isolated power may be the easiest and cheapest way to fix this. The micro should be able to drive 3 small relay coils and the drain on 4 AA ni-cads should be negliable , but we haven't tested this as yet.
The present Software code engages both motor-drives when turning hard (full tank steer) E.G. left turn - Left motor reverse , Right Motor Forward and although this seems like a good idea , I have found that this makes Vincent very vicious to steer at speed. Tests have shown that Vincent is far more drivable if you only engage one side at speed , although this results in a larger turning circle . E.g.: left turn - Left motor off , Right motor forward . I will probably have the code modified to allow for "single motor turns" on the forward and middle quadrants of the remote control and only allow “full rate” ,both motor turns on the lower quadrants of the remote . This should make driving at speed much easier whilst still allowing you to use a “death spin” move if you wish .
Other intended changes to the software , are mostly related to the fail-safe code as the F.S. is a little touchy at the moment . Unfortunately this will probably result in a partial re-write of the code. I have modded the code to allow only full rate turns on the lower quadrents of the remote and this has made the robot very driveable at full power (still touchy but very driveable). I installed optoisolation between the PRC and the radio receiver but cannot say if that made any appreciatable difference . The failsafe light still flashed occasionally during combat , but it made no impact on the fighting ability of the robot . I will start work on the "floating failsafe" code suggested by Brett and we hope this will fully stablise the failsafe code.
The second (presently beta) version software with a "floating" failsafe is finished which may make it less suceptable to radio problems , but I have yet to start testing it . The code changes are far too many to list here.
Some of the new version 2 additions:
- block error rate system for failsafe detection
- cpu frequency shifting code to improve response
- failsafe led flashed during inital boot-up (3 sec) - Bretts idea
- greater stability on initial startup
- reduced sensitivity to glitches when failsafe engaged
I have started working on the final generation of the software with a "invert input" using a fourth channel which will reverse the controls .
Possibly later a companion version of software will allow you to use a second PRC to access up to 7 channels .
One of the latest code changes involved the "startup code" , creating a flashing effect on the failsafe led during initial program start . Apart from the safety aspect of this - it also allows me to see if the micro reboots .
Occasionally , when the batteries were starting to get tired and the fighting / motor load was still intense , the micro would reboot ( as indicated by the flashing led ) without reason .
On one occasion , immediately at power up the PRC jammed on full right turn - and refused to respond to any signals . This happened once during testing just before Robowars II , and after 4 mins of "death spin" finally righted itself . Likely the micro rebooted , but we had no way of knowing this then .
Presently the radio receiver is powered separately and opto-isolation is used between the PRC and the receiver - I don’t think this is needed , but the re-boots may be caused by spikes on the power rails.
The next mod will be to power the PRC and the receiver from the same (small) battery pack . Then power the main drives etc from a totally separate set of batteries . This will electrically isolate the PRC and receiver from any spikes that may be on the main power rails and hopefully stop the micro from "rebooting".
We now believe the "reboots" are now being caused by voltage "dips" as the batteries drain under excessive load , and this was more apparent during this event . I hope to cure this problem by powering the PRC from the same battery pack as the receiver - obviously I will remove the opto isolators during this mod .
Static dis-charge was noticed during the handling of the robot during this event ( likely helped by the wood floor used in all the Victorian arenas ) . The PRC sits open and exposed in the robot at this point and at the very end of the event the micro died again ( 2nd time ) . During the next rebuild - I will encase the PRC to help to protect it against static charges , hopefully this will stop any further micro deaths .
Posted by Grotto:
I was working on a similar project for multiple weapons control
only and ran into difficulties reading more than 1 input channel
without severely losing response times. Mad So I was hoping to see how
you got around it.
And I was wondering if it is still a live project, how the separate
supplies helped the resetting issue.
I have a couple of suggestions to try it it didnt help.
1) Tie pin 4 (reset) STRAIGHT to pin 14(V+) with no resistor
2) Put a de-coupling cap across pins 5+14. 0.1 to 0.01 uf (value
is not critical) as close as possible to the chip, preferably
straddling the chip or under the board. The closer the better.
3) Put a 5.1v zener across pins 5+14 to help reduce high-spike
interference and add (some) static protection.
All these points have been tried and tested on multiple picaxe
projects (on 08, 08m, 18a, 18x chips) and found to be effective
in REDUCING spike and dip interferance/resetting by myself.
Hope youre still around and this is a live thread. Very Happy
Posted by the moth:
O.K. so I should come to the forum more often ...
Nope the thread and the PRC are not dead - I've just been off doing other things .
I have built a Ver II of the PRC which will be "blooded" in combat tomorrow at "Judgment day 2006" . Changes for this version are :
Minor software alterations (nothing significant ) my current version is 4.3
The PRC-2 and radio receiver is being powered from three alkaline non rechargeable cells for a voltage of about 4.6v - I have lots of these and that’s why I used them , 4x rechargeable would produce similar results . The outputs go directly into a 2003 driver chip as per ver 1 but the 2003 is also now being powered from the cells . Each of the outputs of the 2003 are connected to the mimic led's as per V1 but they are now also connected to a 5v relay . The 5v relay contacts then activate the main drive relays . This provides full electrical isolation of the radio receiver and PRC2 from the main drive circuit . I have tried many different combinations of power grouping but I have settled on this one for tomorrows fight .
PRC2 notes of interest .
YES the high frequency decoupling cap is very important - defiantly over the back of the micro if possible. A mid and low frequency cap on the power rail doesn’t hurt either ( I'm using all three)
Consider putting the board in a earthed metal box as RF noise can be a problem
My bot (Vincent) uses 5 noisy drill motors and in full battle all 5 will be running , the resultant RF noise kept resetting the micro until it was put into a RF protected enclosure
The micro will probably run fine at 8mhz all the way thru , but you will need to change some values . I put the drop back to 4mhz in the code , just in-case the 8mhz was adding to the radio problems .
I am presently playing with V5 of the software that has a "inverted" function using a fourth radio channel but register limitations are getting in the way . I will not use V5 in "Judgment day" as its unstable . (don’t ask for it )
I will update my success or failures after "Judgment day 2006"
Well not a great event for my robot , but the important things I needed to test on the PRC2 were completed before the nasty gremlins appeared . The PRC2 competed as stated and during the Saturday performed with only a few minor glitches . The 3 aa cell battery pack provided ample power for a event with no sigh of power loss to the micro or receiver boards . Response time during combat was as good a direct drive with the added isolation of the receiver and micro boards . At one time the robot ran for over a hour in continuous combat / demo's displaying only minor problems and stopping only for main drive battery changes . While this was good for testing it had the disadvantage of subjecting my highly experimental PRC2 board to mammoth jarring and shocks . Unfortunately by Sunday the board refused to run stability and we retired disappointed .
Where to from here ? … Any software at or above 4.0 is stable but some have minor adjustments for problems specific to my robot . The next version including the invert function will not become available for some time as it and another feature will require a rewrite of the code . I will finalize the basic initial software and specs soon . Hopefully a prototype board will become available in the next 6 months (possibly sooner) as I have only just started discussions on board layout and production and the new board will hopefully cure the final few glitches. The PRC board will support some basic configurations and its cost will be decided by the options you build it with . A inbuilt 12v to 5v power supply will allow you to power it from the robots main power and it will then power the receiver alternatively you will be able to power it from the receiver battery pack and not build the power supply . Mimic LED's will be optional and the output can be taken from the uln2003 chip direct or built with the 5v relay option for isolation . The only LEDs that will need to be there are the power and failsafe led's . The minimum component count will be something like a Picaxe-18x micro the 2 LED's , 5v Ps and a uln2003 .Cost will depend on what you want
I wont post again unless something new happens …
The ver III of the PRC was successfully bloodied in Robowars 2007 . It ran stably without problems or reboots despite some serious shocks etc . The PRC used the same basic configuration as Ver II , The PRC-2 and radio receiver is being powered from three alkaline non rechargeable cells for a voltage of about 4.6v . The outputs go directly into a 2003 driver chip but the 2003 is also powered from the cells . Each of the outputs of the 2003 are connected to the mimic led's but they are also connected to a 5v relay . The 5v relay contacts then activate the main drive relays . This provides full electrical isolation of the radio receiver and PRC2 from the main drive circuit . If you have a very noisy (electrical) environment like my robot “Vincent” this is a must . I have added more caps to reduce spikes but these are likely not needed with full isolation from the main drive power. Version III is built on a larger board simply to make it easier to work on for me . I will approach some “circuit” board builders about getting a short run of boards made if there is enough interest in it , you will still have to assemble it yourself but the hard work of connecting wires will be done making them very easy to build . Although I have changed the code slightly – it was only too suit my robot and not to improve performance. I will probably drop the 8mhz from the code as it doesn’t need it ( the main loop runs on 4mhz ) . If you want a experimental board – post here , I expect the cost may be $20 each because of the short run and you will have to buy your own components. Eventfully the boards should be very cheap and might cost as little as $30.oo including just how many parts you want. I’ll try to post more soon .