Automatic Target Project

[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

[Cones]

Hi Calv,

Thanks for all the tips. Bit late though.

I've not updated my post since the other day as I have been busy with the code.

I now have a fully working system.

The master unit has all the menus and modes. I did use an array as you suggested above. I had to use debounce and edge detection for the button presses.

The slave receives the program number from the master then takes care of itself.
So there is only a couple of bytes of data to send. I can have feedback but don't really need it.

I'll do some pictures and maybe a video later and post up the code for you to look at.

The next stage is to do a couple of boxes and get the servos mounted on a frame. Then cobble together some wire frame target holders.

Many Thanks

Mark

[Cones]

A few pictures of the bits so far.

http://s699.photobucket.com/albums/v...get%20Project/

Along with a video of the operation.

http://www.youtube.com/watch?v=2kGE5euLceg

Thanks

Mark