Automatic Target Project

[Fred]

Another update.

Chris brought the target up to the club today. But we had a problem with the control board.

It refused to operate unless it was connected to the laptop as well as the battery. But I said not to worry as I had bought two and would fit the spare one when I got in.

So this is the finished target with the new board and the reset time now set to 1 second.

I left it on cycle for an entire hour and it works perfectly each time.

This is the revised video http://www.youtube.com/watch?v=HLEGV8HCels

We have to now wait till Wednesday evening to shoot at it.

Thanks

Mark

Mark, That is what I want mine to do. Exactly like that!

Does that mean I could use the same stuff as you? (Hopefully)

Would I need a stronger servo maybe?

Thanks

[BigDuncs]

.....how about a radio control as used in a model plane/car etc. That way servo control is all taken care of and all that is needed is a bit of DIY to connect the servos to the targets, the only thing missing then would be making the targets come back up on their own, but using a radio system like that would mean most of the job was straight out of the box which is ideal for someone that doesnt have any electronics or programming knowledge. Just dont use the system near a model plane club

I had a go at this a few years ago but standard servos eg Futaba 148s were not powerful enough to reset Nockover targets. Also, you'd be better not to use 35mhz for the reason you stated but get/use a cheap 27mHz Tx instead.

[Cones]

Mark, That is what I want mine to do. Exactly like that!

Does that mean I could use the same stuff as you? (Hopefully)

Would I need a stronger servo maybe?

Thanks

Hi, Fred.

Yes, you could use the same stuff. Remember a standard Nockover target would be way to heavy for it though.

They are standard Servos we are using. Works fine.

I left it running for an hour and it did about 1800 cycles without a problem.

It could probably do with an off/on switch and an AA battery box.

Thanks

Mark

[eggplant]

Looking good

Couple of questions if you dont mind.
When the target is hit and it falls back, what is stopping it from causing shock damage as it seems to hit pretty directly (is the taped on thingy on the back of the target a foam pad or something?) This is one of the things I was concerned about initially which is one of the reasons why I used 2 servos in my original prototype. And what stops the target bouncing back up itself ?
Are you looking at making it being able to fall on its own too ? I would be interested in your setup if you do, I like the neatness of your design, my only "gripe" would be that it only falls part way back, presumably due to the effort required to lift it back up ?
I like your adjustment idea at the front, think I might pinch it
Mine is working fine now, done a couple of basic program modes - up for so many seconds, down, move to a random or preset position, back up etc and now working on the wireless which is proving a bit harder than I anticipated but it is working. The positioning is only within an inch or so left to right but I am only using a standard motor and not a stepper, it takes its zero position from the left hand switch. I might yet make something with a load of holes in going right accross and count each one with an IR sensor - simply because I have these but dont have a stepper driver and also dont want to change things too much now as its all going well.



Calv

[Cones]

Hi Calv,

The metal frame that support the servo has a protrusion on it that takes any direct plate impacts. The pad is so this lighter plate contacts the switch. Chris made a larger and smaller target plate, you just lift them out to change them.

Weight stops the target bouncing back. But we have yet to try this with an air pistol! (Wednesday hopefully)

The initial designed is based from the one we have shown on the first post of this thread, so we cannot take credit for the screw design. It works well for tuning the target though.

It could be made to fall on its own with a second servo or a small solenoid pretty easily as well.

With the addition of a front shield plate, it can be made to vanish from view when shot. We intend to do this once the design is proven.

I like your design. Can the wire drive slip at all? I was thinking you could make one that works like a 10m target changer? They just use a slipping wheel arrangement on a nylon cord. The electronics detect the slip at each end and cut out the motor.

Thanks

Mark

[Cones]

Here are some detailed photos of the target.

http://i699.photobucket.com/albums/v...t3012Large.jpg

http://s699.photobucket.com/albums/v...t3013Large.jpg

http://s699.photobucket.com/albums/v...t3008Large.jpg

Please scroll through the album for more.

Thanks

Mark

[Cones]

Just a though on making the target fall as well as reset.

If the servo was set so that a small further movement of the reset lever from the rest position pulled a nylon line on the target, you could pull it rearwards again. Then you only need one servo per target.

Mark

[eggplant]

Looking good much better engineered than mine and looks a lot more substantial than it seemed in the original photos.
When I first set up my 1st prototype to see if they would fall when hit, I was very suprised at the force they went down (AA S410 @ 10 yds) which is one of the reasons for using my magnet on a spring and a seperate servo with a "1 way" linkage for lowering/raising. I think I'll stick to that idea for my metal ones but for the pop up paper targets I'll use just one. I think maybe if I had used your fine adjustment setup initially things would have been a lot easier.
I think as long as your targets stay down and dont bounce back (mine did till I stuck a stronger magnet in) then as you say, once the balance is right with a bit of careful positioning etc it should be possible for your design to go up and down with the 1 servo.
Another idea I had initially was a latch like you get on a garden gate, and the target spring loaded in the up position, that way when hit, it fell back and latched in the gate catch which could be released by a servo or whatever to allow it to spring back up. The reason I didnt do that was because I couldnt find a small latch.

Been doing a little on mine tonight, I was hoping to have my basic positioning sorted but things didnt go well today. Changed plan about 100 times but have now decided I'm just going to drill loads of holes in the rail that supports the front of the target (not on vid but where it rests on the board) and have an IR led one side and an IR transistor on the other which will br attached to the target, the idea being I can have the arduino count the holes and therefore get a more accurate position than I can now. (that was my original idea but I tried a few other things - none of which worked!!)
I've also started to redo the falling target on a tray so in theory to move from a falling metal target to a paper one will just be a matter of a couple of screws (or even clips maybe) and a couple of connectors. I will quite probably incorporate the adjustment system you use too.
My only concern at the moment is how pellet proof the metal is that holds the paper target, its cobbled together from left over bits of printer and I dont think it will hold up to many hits, but I suppose if the targets arnt moving when shot at then they shouldnt be hit. Im not sure what else to use, could do with some space age lightweight alloy that wont be damaged by pellets but the nearest I have is .8mm steel which is a bit heavy, and unfortunately I no longer have a welder so everything has to be drilled and screwed (or polymorphed!)

Can the wire drive slip at all? I was thinking you could make one that works like a 10m target changer? They just use a slipping wheel arrangement on a nylon cord. The electronics detect the slip at each end and cut out the motor.

Not sure what you mean here, I dont know what a 10M target changer is ! If by slip, if you mean the belt physically slip on the motor when manually stopped from moving then no it cant, its a toothed belt. I could possibly detect a "stoppage" by monitoring the current drawn from the motor or another method.

Calv

[Rob M]

I don't get why a servo and controller is necessary... Local electronics hobby shops sell motors, gears, geared motors, reed switches, micro switches. With a little thought and a reasonable amount of metalworking skill it shouldn't be difficult to make a simple, self-resetting electric target. I would have done it before now if I wasn't so damn busy!

Well if you have any ideas on how to use the above to make an automatic target, please post on this thread!

I did:

I've had some thoughts about this, it's something I've been thinking about for a year or two, but sadly I have only got as far as making the box and a steel "bell target" face so far. I was going to have a plate behind the hole in the centre of the target that tips back when hit and activates a reed switch, which activates a small geared motor that resets the falling plate. The shaft from the motor will have a round cam on it with a microswitch that keeps the motor on for a while to enable it to return to the starting position after each hit and lights a flashing LED to indicate a hit.

Maybe I've missed something but that seems like the simplest way to me.

But maybe that's not what people want, although I said this was for a Bell Target style effort, I think it would work for any type of falling plate target, althoug it's not as flexible as some of the other solutions on here.

[eggplant]

Quote:
Originally Posted by Fred View Post
Well if you have any ideas on how to use the above to make an automatic target, please post on this thread!
I did:

You did, and it was most helpful, there are probably many ways to do this, and the more ideas from other people, the better.

But maybe that's not what people want, although I said this was for a Bell Target style effort, I think it would work for any type of falling plate target, althoug it's not as flexible as some of the other solutions on here.

I think the issue is that Mark and I are both part way through a project and have both decided on servos for the flexibility.For me also because I find it easier to control a servo quite precisely from the arduino. Controlling a motor this way is also easy but not as precise, and I find it easier to be able to change a few lines of code rather than juggle gears and pulleys about - each to their own, that said, perhaps I am going a bit overboard as it is after all just a target and doesnt need to be particularly accurate as long is it is up (ish) or down(ish). I hope you find time to have a go at your project, I always find it intereting that there can be so many different ways to achive the same goal. Please add any other ideas you have, mine is changing all the time as I keep thinking of things to add or improve, but I enjoy that and ther is no deadline so I'll just plod along until I'm happy with it - then no doubt will see another idea and start modifying again !

Calv

[eggplant]

ok, been doing more work on my one. Sorry the vid is a bit naf but you will see the idea. Description I put on youtube is same as follows for anyone that doesnt want to look:

Youtube link

Sorry about the crap quality, took it on a phone as I dont have a video camera.
This is the new version I am working on now that I know the idea works. The adjusting screw fell out and I didnt notice till after the vid so when the target is in the up position it leans forward a bit too much.
It is now wireless and powered from a 12V battery which can be seen at the back right hand side just behind.
It still runs from an arduino, I had to change a lot of the code and the motor rail to try and get the positioning a bit more accurate, initialy I set the motor moving and then stopped it after a specific time but this wasnt too accurate so I drilled a lot (350 ish) 0.8mm holes in the track at the front and fitted a photogate which counts the holes which now gives an accuracy of about 5mm - 8mm but this varies very slightly at higher speeds as the motor continues to move a couple of mm after it has stopped - dont think I'll bother making it any more accurate as it is close enough for this use.
It can run in standalone mode but only 1 standard sequence at the moment but running from a pc or laptop you can (just about) see this on the laptop I coded in VB, its not finished yet but works ok. The main window allows manual control of the up/down and position/speed as you can see. The next window is the program mode, I only have 3 at the moment but adding new program modes is dead easy now the control/communication is working.
You can select the number of "players" by name and it will run through the specific program for each player.
Now the hard bit is done, i.e. the wireless communicaton, motor and servo control it is fairly easy to expand on. I plan to use another arduino with an LCD display and some buttons to set the program modes etc which will save having to use the laptop but I will still develop the software on the lappy too as it is more versatile.
I need to just finalise the mechanical side now and tidy it up. I'm also going to add a bearing onto the rail at the bottom as when slow speeds are used it gets a little sticky towards the ends when the tension on the drive belt changes. I would have liked to have used a different method of controlling the motor, either an H bridge with the existing motor or a stepper motor but I have neither so its staying as it is. A stepper would have made positioning and speed control easier but thats life!
The target holder also needs redoing, this was just a couple of bits of metal roughly screwed together to see if it worked ok. The 2 round things you see on the back of the target are magnets which hold the paper target on.
The tray thing that holds the servo/target fastenes on with 3 screws, you cant see much of the wiring to the tray but it all plugs in on a sort of harness, it is tucked away underneath at the moment but the idea is that I'll put a plug on the back of the tray so that it can be removed and changed for another in a minute or so so that I can put on a different sort of target, i.e. the duck that falls down/comes back up or a different size target. Using a knock down type target I can also count the number of hits (and misses as long as the pellet hits the back or front of the assembly (back panel not in place on the vid).
Hope this is of interest, Im open to any ideas for improvement/changes etc.
Sorry again for the crappy quality vid.

[Cones]

Thanks for posting the update.

I like the remote operation, I would be interested in the details in the radio link side of things. Did you use Xbee units or something else?

I am now considering two Arduinos for a 5 target, turning target system. One at the target end to drive the servo code and the other on a push button box to start the timing sequence etc. An LCD might be neater for changing the modes and things, but I need to find an example menu system to give me a head start into the coding.

I've not bought the Arduino units yet but have found the DFrobot DFRoduino Mega for about £25 each. They also make a APC220 radio comms unit pair for £34 and a servo I/O shield for £8 that the radio unit plugs into. If I did use the above I would probably have to hardwire the LCD though as the shield kit would not fit onto the other I/O shields.

Thanks

Mark

[eggplant]

Im using the dfrobot arduino romeos as these have built in power points for servos and motors so saves some messing.
The APC220's are what Im using, dead easy you just treat it as a standard serial port so you can basically do what you want. The way I have done mine at the moment is simply send 4 bytes from the pc, the 1st being a "command", the others being info for the command, for eg "M",50,2,0
The arduino code picks up the M,(move) then in this case 50 is the position to move to, 2 is the speed, the zero isnt used with my M command but I found it easier just to send a zero rather than working out how many more bytes to expect, the R command (raise) would be R000. Once the arduino has the 4 bytes, it sends back "OK", until OK is recieved by the pc it wont send any more - otherwise it can easily get confused. ITs a lot of years since I messed with any sort of serial programming and Im sure you can implement the RTS line but I have just done it my own way since it doesnt have any standards to comply to.
LCD's are odd creatures, well not so much LCD displays them selves but the controllers. There are several types, a standard LCD using the common hitachi 44780 controller is dead easy to use either with the built in arduino librarys or your own - BUT that one, like a lot tie up a load of I/O pins which is naff so for my other project (camera controller) I used an I2C graphic display so keeps plenty of I/O ports. The problem I had (lack of research on my part) was there was bugger all code readily available for the display (that I could get to work anyway) I got so had to pretty much do my own librarys with bits and bobs for the circle/rectangle etc modified from other peoples code - I'm not very proficient at all in C.
Heres an example of the GLCD I used, can of course display text, this one is a 128 x 64 pixel with a KS0108 controller onboard (I think its a 108, from memory, can check if you need me to) and was about £30. It can display 21 x 8 lines of charachters too - lot more versatile than the standard 2 or 4 line by 16 or 20 displays, and once you have the libraries setup you just LCD.print 'HELLO', or LCD.draw_circle (int x, int y, int radius, int color) etc etc

BEWARE, the dfrobot userguides have errors in the sample code !

Seems like we are almost exactly the same track here, shame we dont live closer.
Let me know if I can help in any way, I'm not too good at C as I said so my code is far from perfect, but I have some experience with micro controllers and some vb programming in general (did quite a bit with PICS years ago) but dont have a programmer any more which is why I went for the arduino - 4 arduinos is less than the cost of a decent pic programmer, plus theres no circuit to build.


Calv

GLCD Another

EDIT

Maybe you know this already, but there are 2 main variations on the chip used in the common arduinos, the 168 and the 328. The 328 has more memory and also quicker when uploading your program (sketch).

[Cones]

Just a quick bump for this thread.

I have just bought some parts to start looking at this project again.

2 DFrobot Mega boards
2 DFrobot Mega I/O shields ver1.1 with Xbee sockets
2 Xbee Radio units
1 Serial LCD Display 16x2

My progress so far with the code, is I can now send information from the master to the slave unit. I can send information to the LCD. I can drive the servos to fixed positions on the slave unit.

I now need...

1.) A proper menu system
2.) Up / Down menu and a start push buttons
3.) Several mode selections in the slave unit for the different sequences
4.) Timing software in the slave unit

In use the idea will be to select the mode on the LCD.

Rapid Fire 8 Sec
Rapid Fire 6 Sec
Rapid Fire 4 Sec
All targets To Front

Then pressing start sends the mode and go signal to the slave which will the run the servos.

Thanks

Mark

[eggplant]

Hi,

Glad its going well.
I havent done a lot to mine recently, mainly due to the weather but I havent forgotten about it and am collecting odds and sodds that might come in handy for it. I plan to redo a lot of the mechanical part and I may change the movement system to use a stepper motor rather than counting holes - I had nothing around at the time and made use of what I had. I will also redo the up/down mechanism as its sort of cobbled together and me still use a method like your one. Im going to have mine run from a phone or PDA rather than a laptop as its less hassle to move about, I've just this week as it happens connected my Combro to my PDA and written a program to display the FPS etc, Ive also connected one of my wireless devices to the combro, just waiting on a bluetooth adaptor and a cable to arrive then I can have a go with it on with my phone too, my phone needs a hacked cable to access the serial port directly and I only have the one which I need so I'll have to wait. Couple of pics of my PDA at the end, software not 100% finished, just needs tidying up a bit but it does the job.

On to your one

First off, I would have gone for a larger LCD, simply because it would mean less scrolling up and down for the menus, which would in turn make using it easier and also make the coding a bit easier. But not to worry, I used a 2 line on my camera controller at first and it was fine once you got used to going through the menus.

Do you have a breadboard or some stripboard? I would get both as it makes it easier to keep things a bit organised whilst plugging things in and out, making changes etc.

I always find it tricky doing anything with "2 parts" as its difficult to try and get just one right initially without the other, then just when you get one part right it always turns out that it needs changing to make it work with the other, then vice versa and round in a circle we go lol.

I would try and start with one or the other, probably the target part as this can be tested easily and once you can get the arduino to control the targets in a set routine then its just a matter of sending a command to the slave telling it what to do. For eg, if you had say 2 led's on the slave, and 2 parts of your program called "void led1" and "void led2" both worked fine and what they did was flash the led 5 times. You would then have in your void loop a piece of code that basically waited for a signal down the xbee (I would initially test plugged into the usb and send down the arduino serial monitor). So you would have something like: (not in proper code but you will hopefully get the idea)

void loop()
whilst no data in


do nothing


If data in = "LED1" then


led1 ' call your LED1 part of the program as mentioned above


If data in="LED2" then


led1 ' call your LED2 part




Thats the basic way I would go about it, all you need to do then is send "LED1" or "LED2" down the serail/xbee or whatever and it should do its thing.

I would go a step further though, rather than just rely on one way communication I would have then "talk" to each other, for eg.

from master (pc initially), send "ABCDE"
slave waits for "ABCDE" to be recieved and does nothing till it is, perhaps have an LED come one once it has been recieved.
Once ABCDE has been recieved by the slave, it then sends back "OK, THANKS", the master (pc for now) doesnt send anything else until it has recieved the reply. (again an LED to indicate)
I would then go a little further and have them do the above every few secs to confirm that the connection is there and have your program take action accordingly.

If you dont have some sort of 2 way communication you wont know if the connection is lost, and also in theory but not likely, if someone else nearby is playing with an xbee it could confuse things as you can imagine.

Thats basically how I would do the slave part, I keep saying this but do it plugged into the pc initially so that you can see whats going on.

Ok, slave bit sone and can respont to commands it recieves from the pc its on with the master unit.

First thing, send and recieve as above to make sure it works !!!, it will of course. Once it is confirmed they can talk to each other I would first off program the part that I mentioned where a signal is sent back and forth every few secs to confirm connection, its easy to do, use "serial.available" since the wireles modules are basically a serial port without wires.

Then the menu, I hate these - because my C skills are not too good I struggle a bit but the basic idea is:

eg if we have 5 menu options, but only 2 lines of LCD we obviously need to scroll up and down.

have an array or a list of sorts with each menu item in it

1.MENU ITEM 1
2.MENU ITEM 2
3.MENU ITEM 3
4.MENU ITEM 4
5.MENU ITEM 5

and a counter, say 'x'

so x = 1, menu item 1 and menu item 2 need to be displayed
x = 2, then 2 and 3 need to be displayed and so on.

have a routine in your program (eg, "void display (x)" to display the menu according to the value of x, and call this void when the display needs updating, do this rather than manually change the display here there and everywhere in your program whenever a button is pressed.

a button to scroll up (B1), and one to scroll down (B2) (one to "accept" would be handy too lol)

so in our program we start with x = 1, and call "display(x)" this will pass the value of x to the display part of the program (obviously) and it can then be processed, not sure how your lcd works but the sample below in half C half english should explain !

void display(x)

LCD.writeto line 1, menuitem (x) - x would be 1
LCD.writeto line 2, menuitem (x+1) x + 1 would be 2


so if x =1 as above, menuitem1 is displayed on the 1st line, and menuitem2 on the second line (x+1 =2)

programming the buttons is easy, if button A is pressed, increase x by 1, if B is pressed, decrease x, obviously check that it doesnt go below 1 or above the amount of items in your menu.

So, we press button A to increase x, so x is now 2. We then call our display routine again as above

void display(x)

LCD.writeto line 1, menuitem (x) - this time x is 2 so menuitem2 is on line 1
LCD.writeto line 2, menuitem (x+1) - and x +1 is 3 so menuitem3 is on line 2


so, it has now "scrolled". as there are 2 lines and only 1 line the "current" one, I would put an indicator at the beginning of the selected line such as a ">" and only scroll up when that is at the bottom, and likewise only scroll down when it is on the top line.

I hope that all makes sense !! Its a bit difficult to explain in writing but it should hopefully give you something to go on. Any probs just yell and I'll try and help.

Calv

http://www.calvsplace.co.uk/gun_stuff/dell_1_xs.jpg

http://www.calvsplace.co.uk/gun_stuff/dell_2_xs.jpg