Speed Trap

The project under consideration is a speed trap for R/C Model Warship combat.

The basic setup and function:

Setup: 2 lasers are set up, parallel to each other, close to the water (but above the waves) projecting across the speed trap, into 2 sensors, call them A and B. Most ships are longer than the trap, but some may be shorter, or so low to the water that only a piece of the superstructure interrupts the beam. The sensors are probably less than 1 ft apart.

As the ship goes through in each direction (say first is A to B), it interrupts the light beam at A, tripping the sensor, and then, a short time later, interrupts B. Going the other direction, of course, reverses this. It should be able to handle entry from either direction at any time (in other words, no directional preference or requirement - you may have several go AB in a row and then some come back and BA with others not).

The critical information is the interval between A and B each being initially tripped. Keep in mind that B may be tripped while A is still active (the beam still occluded), as ships range up to about 2 meters in length.

What I would like as the end result is to generate a stream of pulses that I can send to a bike computer as the readout - or, to put it in more functional terms,

Sent pulse stream that gives a result of, say, 10 MPH on the bike computer.
Once the interval is timed, change the pulse stream to an interval that the bike computer reads as the model speed based on our calculation (not a true scale), that will, in turn, bive a seadout in the 22-60 knot (or mph is fine) range for, say 10 seconds.
After 10 seconds, return to standby pulse stream of 10 MPHto indicate ready for next ship.

I am trying to wrap my mind around the easiest/best way to do this. A latching relay would probably work, and I could tweak around the delays. Or creatively programming a second Picaxe to act kind of like a flip-flop
(on A or B turn pin X high,
on the other turn pin X back low),
and read the pulse thus generated with a second Picaxe's Pulsin.

My electronics is a bit rudimentary, but are there some "simple to implement" solutions, either in hardware or software that I am overlooking?

Oh, almost forgot one of the parameters. The time it takes to transitin between sensors should be on the order of large fractions of a seconds (say 0.1 to 0.6 second).

Thanks in advance for any suggestions.

Wreno

Edited by - wrenow on 21/12/2006 18:44:08

At a first stab and untested I would look to generate an interrupt from the inputs and then jump to the relevent sub routine to count the time to the next input.

Ok, nice project, and I think this is a classic state-transition type problem.

In theory as the ship moves through the lasers the states of each sensor move through a 'gray-code'. i.e only one sensor changes at a time.

A B
0 0 Ship outside lasers
0 1 Ship beginning to cross B
1 1 Ship crossed B and A
1 0 Ship clear of B but still crossed A

So you really want to know the time interval between the different states. So you write code to detect the states and to time between them.

In practice, with choppy waters, missile attacks and depth charges rocking the ship (!) I think you are likely to get some state-changes outside of the theory - so you'll have to account for these !

Could do all this with a Picaxe 08M, and have a serial LCD to display the speed on.


Edited by - jeremy leach on 21/12/2006 20:40:11

You should be able to do this with a single quad Schmitt input NAND gate (no software development required). Use two gates to form an RS flip-flop, the output of which controls a third gate that is configured as an astable oscillator. Start by manually setting the RS into a state that inhibits the oscillator. Use the 'first' opto trigger to flip the RS to enable the oscillator and the 'second' opto trigger to flip states back to inhibiting the oscillator.

This should produce a burst of pulses during the period between the first and second triggers. Adjust the oscillator frequency to scale the number of pulses received by the bike counter during this period.

You will need to capacitivly couple the opto trigger pulses to the two Schmitt inputs of the flip-flop and pull-up them up with resistors. But you would probably have to use some conditioning circuitry even if you had used a PICAXE, rather than a quad NAND gate.

Here is an untested suggestion for sensing occlusion of sensor A and

then sensor B, or vice versa, with uncalibrated timing--psuedocode,

since I'm not really experienced with the picaxe. When the first

occlusion is detected, a counter starts and runs until the second

occlusion. No tests are made for unexpected conditions.

<code><pre><font size=2 face='Courier'>
Symbol Cntr = b0
Symbol FlagA = b1
Symbol FlagB = b2

start:
FlagA = 0
FlagB = 0
Cntr = 0 ' not really necessary

main:
inc Cntr
if pin1 = 1 then ' assuming pin1=1 means sensor A occluded
if FlagA = 0 then
if FlagB = 1 then ' B to A transition detected
goto CalcSpeed
else ' begining of A to B transition
Cntr = 0
FlagA = 1 ' this notes A occluded &amp; debounces
endif
endif
endif
if pin2 = 1 then
if FlagB = 0 then
if FlagA = 1 then ' B to A transition detected
goto CalcSpeed
else ' begining of A to B transition
Cntr = 0
FlagB = 1 ' this notes A occluded &amp; debounces
endif
endif
endif
pause 10 ' 10 milliseconds; Cntr val of 255 = 2.5 seconds
goto main

CalcSpeed: ' Cntr = 100ths of seconds between sensor occlusions
' do what is needed to calculate and display speed
pause 10000 ' wait 10 seconds for ship to pass
' maybe check to see that both sensors are cleared
goto start
</font></pre></code>

There must be dozens of ways of doing this depending on accuracy required.
I'd be tempted to go down the interrupt route. Perhaps hippy can give you a lesson on timers? Or you could have an ext osc or timer/astable and use the count command. So many options...

Thanks for all the replies.

Jeremy - &quot;In practice, with choppy waters, missile attacks and depth charges rocking the ship (!) I think you are likely to get some state-changes outside of the theory - so you'll have to account for these !&quot;

No missle attacks nor depth charges in R/C Model Warship Combat (CO2 powered cannon, no pyrotechnics), and running the speed trap is not done while attacking or under attack, so not an issue.

Otherwise, your analysis of what needs to be done is correct (except for the case mentioned of ships too short or too low to occlude both sensors at once as a possible state).

Xstamp - &quot;You should be able to do this with a single quad Schmitt input NAND gate (no software development required). Use two gates to form an RS flip-flop, the output of which controls a third gate that is configured as an astable oscillator.&quot;
You are a bit above my pay-grade here (remember my &quot;rudimentary on electronics&quot; comment? However you have given me enough information to start looking into those avenues (gotta learn somewhere).

lbenson - your program appears to be pretty much along the lines I was thinking. I plan to look through it a lot more closely. It may well form the initial platform. Thanks.


Dippy - yep, tons of options. One reason I threw it out there for what various more experienced than me might consider the simplest/easiest/cheapest solution.

Again, thanks for all the input.

Wreno

The proposed quad NAND circuit is much simpler to draw than my attempt at a description would suggest ( understand that the it will soon be possible to post schematics on this forum).

It certainly would be generally useful for you to read up on using Schmitt triggers to clean-up pulses and edge detection with capacitors etc, because its not often possible to connect remote digital sensors directly to a microcontroller and obtain reliable operation. And once you start thinking about this &#8216;dumb&#8217; conditioning circuitry, you can sometimes find a solution than does not even require a micro to do the job!

Nand latch: <A href='http://www.play-hookey.com/digital/rs_nand_latch.html' Target=_Blank>External Web Link</a>

I haven't looked at doing it in any depth, but I'm not sure a simple NAND-latch or similar would do the job. Triggering on A or B is easy enough, but then termination on A or B is dependant on which was the trigger, and complicated by the fact that the trigger may still be present when termination occurs. I may be wrong.

Jeremy's idea of a state machine seems the best way to go, and that can be reduced to simply looking to see if A or B triggers, then waiting for B or A to trigger later. Effectively it's creating that NAND-latch in software.

I'd probably implement it as a two PICAXE-08M solution at 8MHz. One polling A and B, setting an output high when triggering occurs and then, knowing if it were A or B, waiting for the other to trigger to set that output low. The second simply timing the pulse with PULSIN, then generating whatever's needed to display the result.

You might need some diode buffering and capacitance on the two trigger lines so if brief triggering occurs you can still determine which it was after initially detecting it.<code><pre><font size=2 face='Courier'>Do
Do : Loop Until pin1 = 0 And pin2 = 0
Do : Loop Until pin1 = 1 Or pin2 = 1
High POUT
If pin1 = 1 Then
Do : Loop Until pin2 = 1
Low POUT
Else
Do : Loop Until pin1 = 1
Low POUT
End If
Loop </font></pre></code>

You can probably improve the accuracy ( response time / latency ) of the above solution by diode-mixing both triggers to give a single trigger pin, and interrupt for triggering should be even better.

You could replace 'High POUT' with starting a timer and 'Low POUT' to stop it and doing everything on one chip, but that is obviously more complicated. It's a trade-off between the greater cost of a two-chip solution with simpler software, and the effort of a single chip solution. The low-cost of the PICAXE often makes distributed processing like this quite practical and speeds development.

And, <i>Why two Low POUT's ? Why not a single Low POUT after the End If ? </i>

That's so the POUT line is brought low as soon as possible at termination. At the Else, there's a hidden GOTO which would add an extra delay before setting the line low after End If, so the length of the pulse when triggered by pin1=1 would always be slightly longer if that were done, giving an unfair advantage if one knew which way to sail through the speed trap !

Edited by - hippy on 22/12/2006 13:40:59

hippy... &quot;the trigger may still be present when termination occurs&quot;. This potential problem is overcome by using a series capacitor and pull-up resistor on each of the gate inputs. That way only the triggers negative edge gets through and the input is not held low.

That would help, but there could be multiple triggers as 'rigging' passes through or the boat bobs up and down.

Having thought further, one latch for each AB and BA possibility, triggering on (INa&amp;/Qa&amp;/Qb)|(INb&amp;/Qa&amp;/Qb) and terminating on (INa&amp;Qb)|(INb&amp;Qa) with the timing pulse being Qa|Qb wouldn't be too hard but would probably be more than just a single set of gates and simple wiring. I can also see a potential problem with A triggered, B triggered, both cleared and then A triggered again as the ensign at the back of a boat re-triggers the latch ( or similar scenario ), although additional resets ought to sort that out.

I wouldn't say it's impossible to use only hardware but this is an area where 'programmable logic' can often be better than traditional gates, being single chip, less wiring, easy logic re-design, and it's easier to deal with race conditions and complex conditions.

A quick google search gave this photo of a home built speed trap. <A href='http://www.nwlink.com/~pfleming/SupportItems.html' Target=_Blank>External Web Link</a>

http://www.nwlink.com/~pfleming/SupportItems.html

I have used the RS flip flop approach for measuring vehicle speed from pressure switches driven from tubes placed across the road (not only switch bounce but generally dirty signals. However, multiple triggers did not cause problems because the first negative edge arriving at the 'S' input flips the RS and it stays in that state until the first negative edge arrives at the 'R' input. Can't wait for schematic support on this forum!

I agree, a simple RS flip-flop can work well in that situation, but isn't there extra complexity with having to deal with entry from either direction ?

If A is Set and B is Reset, entry from B-to-A just creates another Reset which won't set Q, hence needing two RS's at least.

How very true. I didn&#8217;t have to accommodate people driving on the wrong side of the road. Looks like one quad NAND gate and a 555 oscillator then. Hey, how about using one of those new fangled PICAXE thingies?

Hippy -
&quot;I'd probably implement it as a two PICAXE-08M solution at 8MHz. One polling A and B, setting an output high when triggering occurs and then, knowing if it were A or B, waiting for the other to trigger to set that output low. The second simply timing the pulse with PULSIN, then generating whatever's needed to display the result.&quot;

This is one of the thoughts I had had as well. Seems a pretty sensible solution. Probably be OK with 4 MHZ, as I only really have to have about 30 increments between about .2 and .5 second traverse times under the current plan. And I can raise the transit times by spreading the sensors, if desired.

Keep in mind that we have a speed trap sometimes available in our club, but many do not. This is partly to make the device available to other clubs relatively easily. Ours is at <A href='http://www.ntxbg.org/pgBattleStations/pgBattleStations.htm' Target=_Blank>External Web Link</a>
Unfortunately, the display, which took up a lot of the design, is no longer available surplus at bargain prices, making it incredibly costly to duplicate. Replace it with a $15 bike computer, a couple of $3 Picaxes, and a handful of other inexpensive components, ansd it becomes readily accessible to others.

Thanks again for all the suggestions and analysis. I am certainly learning a lot (including where I need to read up).

Wreno



Edited by - Wrenow on 22/12/2006 23:02:05

That display does look nice. Rather than use a bicycle computer it might be worth considering using 1&quot; 7-Segment LED's which could quite easily be driven by three 4026 latches ( see PICAXE Manual 3 ).

I picked up an old clock with 2.5&quot; 7-Segment LED's for almost zero cost. Weirdly wired and a bit more complex to do but a nice big display.

Running at 8MHz would give better resolution when it comes to s=d/t and scaling, but that's something to play with once you get anything working. You can even prototype the system and use SERTXD to send results to the Programming Editor Terminal so you can get the algorithms tested and worry about the display later. That's all part of what makes it fun using PICAXE's.

A question here regarding forum usage (on this thread). When I try to edit the message I posted, to fix copied comments in the program which I didn't modify, I get an opportunity to edit my post and enter username and password, but when I click the button &quot;Reply to Topic&quot; (why shouldn't it be &quot;Modify Post&quot;?) I always get &quot;Page Cannot Be Found&quot;. What do I need to do?

&quot;Reply to Topic&quot; is an anomaly, and I would suggest &quot;Post Changes&quot; or similar. It is something one gets used to and simply ignores, but I can see how it's confusing.

As to &quot;Page [ or Server ] cannot be found&quot;, that's usually something having hiccuped / crashed / borked somewhere on the internet between you and Rev-Ed. It may be a problem at Rev-Ed's end but could equally be elsewhere - In the past few hours I've been getting that happen with a number of web sites I've tried to visit.

When it does happen after you reply, use your browser's Back button and try &quot;Reply&quot; again. It will often work if you give it a little while.

When it doesn't, I go back, highlight the text and copy it into a document which can be saved, then pasted in to be sent later when everything sorts itself out.

Edited by - hippy on 23/12/2006 03:31:57

Another suggestion regarding the display, nmight be a Tx/Rx pair of modules and send the speed result back to land.

For the Large display, how about something like the one in Rick Harris&#8217;s
post:

<A href='http://www.rev-ed.co.uk/picaxe/forum/Topic.asp?topic_id=4497&amp;forum_id=24&amp;Topic_Title=Driving%2B5%2B7%252Dsegment%2Bdisplays%2Bwith%2Bone%2BPIC%253F&amp;forum_title=No+new+posts+please%21+17
' Target=_Blank>External Web Link</a>

&#8220;Powered&#8221;, by 4026 and 2803

See also Hippy&#8217;s parallel post &#8220;7-segment LED multiplexing&#8221;

e

This cleans up the comments in the prior post of the program, and adds a test for out of bounds condition--first sensor detected and second one not detected within 2.55 seconds.

<code><pre><font size=2 face='Courier'>
Symbol Cntr = b0
Symbol FlagA = b1
Symbol FlagB = b2

start:
FlagA = 0
FlagB = 0
Cntr = 0

main:
if pin1 = 1 then ' assuming pin1=1 means sensor A occluded
if FlagA = 0 then
if FlagB = 1 then ' B to A transition detected
goto CalcSpeed
else ' begining of A to B transition
FlagA = 1 ' this notes A occluded &amp; debounces
endif
endif
endif
if pin2 = 1 then
if FlagB = 0 then
if FlagA = 1 then ' A to B transition detected
goto CalcSpeed
else ' begining of B to A transition
FlagB = 1 ' this notes B occluded &amp; debounces
endif
endif
endif
if FlagA = 1 or FlagB = 1 then
inc Cntr ' count # of 100ths of seconds since 1st sensor occluded
endif
if Cntr = 255 then ' 255 passes (2.55 seconds) since first sensor detected
' without 2nd detection. Process error and restart.
goto start
endif
pause 10 ' 10 milliseconds; Cntr val of 255 = 2.5 seconds
goto main

CalcSpeed: ' Cntr = 100ths of seconds between sensor occlusions
' do what is needed to calculate and display speed
pause 10000 ' wait 10 seconds for ship to pass
' maybe check to see that both sensors are cleared
goto start
</font></pre></code>

Running on from the POV discussion you could make a big 7 seg display quite easily by putting a line of LEDs on a horizontal drum and rotating it. Maybe send the numbers via IR to a picaxe 08m on the axis of the drum.

Once again, thanks for all the help and commentary.

Hippy, you certainly have the issues pictured right as to multiple possible triggers as the superstructure passes through, including a possible ensign at the end. And the bobbing (especially on a loaded tanker).

As for alternate displays - keep in mind that the display will usually be read in bright sun. Many LED and LCD displays wash out and are hard to read under these conditions without hoods, or draw a lot of power. A bike computer is designed for bright sunlight, and is very visible. Plus, it only takes a 2 wire attachment to the system, and you can hold it wherever it is convenient. Size is not really an issue. The only reason our speed trap has the ginormous magnetic airline terminal display mounted on it is that the displays were available &quot;on the cheap&quot; surplus, and were well suited to viewing in daylight. Well, that and the coolness factor.

A TX/RX would certainly work, and make you wire free, but then one part gets separated from the other and misplaced, 2 separate power systems are definitely required (additional &quot;failure points&quot. Plus there is always <i>some </i> guy who will want to blame the glitches in his ship on &quot;interference from the speed trap radio.&quot;

We actually had one captain complain that one of the opponent ships had such bad RF noise (from the ESC) that it EMP'd his RX and killed it as they passed. %) However, no other ships had problems or glitches around the &quot;EMP generator.&quot; And, it was a factory produced, shielded, unmodified, ESC in common use (a Proboat model - Proboat and MTroniks are both common in our club due to being waterproof). And, yes, his motors were properly capped. Caused a lot of humor amongst our EE guys (one a power supply designer, the other a network and wifi design guy).

Wreno

Edited by - Wrenow on 23/12/2006 16:37:04

This has become my first ever picaxe project. I wired it up (PHAnderson breadboard), put inputs from the sensors (in this case, pushbuttons) and an output led for test purposes. Presto, lights and messages back to the terminal on the PC. Changing the code from the structured &quot;IF...ENDIF&quot; shown earlier to GOTOs saved 15 bytes of program code. GOTO not necessarily deprecated for picaxe.

<code><pre><font size=2 face='Courier'>
' Project: measure time between activation of 2 sensors
' Target: PicAxe 08M

Symbol Cntr = b0
Symbol FlagA = b1
Symbol FlagB = b2

let dirs = %10010 ' set pins 3 &amp; 2 input from sensors, 4 output to LED
high 4 ' test led on
pause 500
low 4

start:
FlagA = 0
FlagB = 0
Cntr = 0

main:
if pin3 = 0 or FlagA = 1 then GoPin2 ' assuming pin1=1 means sensor A occluded
if FlagB = 1 then CalcSpeed ' B to A transition detected
' begining of A to B transition
FlagA = 1 ' this notes A occluded &amp; debounces
sertxd (&quot;A to B &quot
high 4 ' test led on
pause 250
low 4
GoPin2:
if pin2 = 0 or FlagB = 1 then IncCntr
if FlagA = 1 then CalcSpeed ' A to B transition detected
' begining of B to A transition
FlagB = 1 ' this notes B occluded &amp; debounces
sertxd (&quot;B to A &quot
high 4 ' test led on
pause 250
low 4
pause 250
high 4 ' test led on
pause 250
low 4
IncCntr:
if FlagA = 1 or FlagB = 1 then
inc Cntr ' count # of 100ths of seconds since 1st sensor occluded
endif
if Cntr = 255 then ' 255 passes (2.55 seconds) since first sensor detected
' without 2nd detection. Process error and restart.
sertxd (&quot;ERROR&quot;,13,10)
goto start
endif
pause 10 ' 10 milliseconds; Cntr val of 255 = 2.5 seconds
goto main

CalcSpeed: ' Cntr = 100ths of seconds between sensor occlusions
' do what is needed to calculate and display speed
sertxd (&quot;speed is &quot;,#b0,13,10)

Pause10:
high 4 ' test led on
pause 10000 ' wait 10 seconds for ship to pass
low 4
if pin3 = 1 or pin2 = 1 then Pause10 ' check to see that both sensors are cleared
goto start
</font></pre></code>