Coder required

Good morning guys and gals,

I'm looking for someone prefrebly UK based to quote me on a cost for producing code for a project i'm working on I have got the basics of coding down, and have produced a prototype on an industrial system (something I work with regularly). The idea of the project is to produce an interactive shooting gallery game, I will highlight some desired features below however I have some quite detailed plans that I would rather discuss face to face / skype ect.

Multi layered menu for selecting game types and changing parameters (lcd shield)

Variable target amounts up to 10

Each target would have an impact sensor, servo, and 3 leds

Bluetooth\wifi connected to allow changes to be made up range.

Saving of high scores and producing a report post round.

For a more detailed brief please contact me at alunduk@gmail.com

Hi Alunduk,

Sounds interesting. How far away are the targets and how any do you envision using?

I assume you're using a laser and a light sensor of some sort.

A friend of mine was also building a range like this. I should ask him what he used.

Pat.

patduino:
I assume you're using a laser and a light sensor of some sort.

He stated he was using an impact sensor (!).

If the targets are simply up/down, perhaps solenoids rather than servos?

Bluetooth\wifi connected to allow changes to be made up range.

Why have an lcd screen, then? A cheap linux tablet can display an interface as pretty as you like with a bit of javascript. It might be worthwhile to drive the whole game from the tablet, and just to have the arduino in charge of putting the ducks up and dropping them down again. This makes programming different games, menus, scenarios much easier. Perhaps a serial connection from the linux machine to the arduino might be the go.

there are no moving targets just metal pellet catches with the piezo element attached so it can detect the vibrations of a hit from an air gun.

The tablet sound like a very interesting idea that I will look into for a MK2 but at the moment I'm trying to keep the overall build cost down. I was also thinking about wifi comms so that the game and options could be set up from down range

Alunduk:
The tablet sound like a very interesting idea that I will look into for a MK2 but at the moment I'm trying to keep the overall build cost down.

Well, you specified "Bluetooth\wifi connected to allow changes to be made up range." If it's communicating by wifi anyway, then doing everything that doesn't have to be on the ardiuno on a linux box will be cheaper/easier.

I'd be inclined to have the arduino connected via wifi to a webserver. The arduino would transmit messages about events (targets being hit) to the server and the server would transmit commands to the arduino. The server would also supply a basic web interface that would be accessible to a web browser (the webap would have to poll for status updates - once a second would probably be ok).

Alternatively, you could ditch the man-in-the-middle and write the client part as an angularJS app, which I am a fan of at present.

Essentailly, the arduino would accept JSON POST requests and reply with JSON. Alternatively, it might be better to do the request as a GET with a querystring having a fixed format. That way you don't need a JSON library on the ardiuno and you don't have to worry about dynamically allocating space for the incoming request. Heck - you could even use a REST style URL for each duck.

The request would be just a "give me status", or it would be an array of what ducks you want up and what LEDs you want lit.

The response would be a JSON array of what ducks were currently up/down. It would be sensible to have the arduino drop the ducks when they are hit, as that is something that you would like to be fast. Building JSON doesn't require a library you just write the stuff you need.

It really would be quite a bit easier than attempting to do it as a set of horrible LCD menus (I'm not a fan of LCDs) - pins for the LCD, pins for the buttons, memory for the messages, and then you have to code up the game itself. It's a big job, and doing it in C++ in the limited space of an arduino makes it even worse.

See my simple demo page in the playground.

Each target would have an impact sensor, servo, and 3 leds

That's a lot of wires. It might be sensible to do your ducks as blocks of 4 or 5, with shift registers so they can be chained.

(asking google) There are quite a few 4-bit shift registers around. This one http://www.ti.com/lit/ds/symlink/sn7494.pdf does it all, and using it has the advantage that you only need a bag of one kind of chip. But, it's complicated to use. Maybe more specific ones would be better.

The simplest way, really, might be one microprocessor per duck. There's a fair bit of state, after all: each of the three leds can be on or off, each duck can be up or down, and you might want to be able to choose to not drop a duck on impact (if, for instance, the game hasn't stared yet). One processor per duck means that each can be a module that you can swap out if its defective. They'd all talk to the central arduino with the wi-fi: perhaps i2c. i2c means three wires (clock, data, ground), or just two if these things are all bolted to a chassis.

The main concern I have is the impact sensor. You can't have the arduino poll these things, because it's transient. So there has to be some kind of latch/reset.

Unless I'm missing something obvious, ten ducks means either ten processors or quite a bit of auxilulary electronics. ATTinys, BTW, are a buck and change each if you buy a lot of em. (Oh, they also do chips built for automotive applications) You could build one duck with an arduino as proof on concept. Maybe three ducks, a controller arduno with the wifi. The angular webapp with the necessary code could live on an SD card. That makes it all nice and self-contained. If you go commercial, you'd use something cheaper for the ducks. Or even then: maybe not. A leostick is 20 bucks if you shop around.

So.

Each duck in my proposal would have a cheap ardiuno, servo, three leds, impact sensor, and a DIP switch to set its 12c address, permitting 16 ducks. The i2c address would be a block of 16 addresses somewhere sensible that is not going to collide with other hardware.

Each duck would connect to the i2c bus, and would also connect to an interrupt output line. This would be pulled up on the controller - the ducks would let it float (pin mode INPUT) or would pull it down to indicate that an impact had been sensed.

Each duck would run i2c in slave mode. It would accept a packet to set or interrogate its state and would reply with state.

The state of each duck comprises the state of each LED, duck up/down, and whether or not it should respond to impacts by dropping the duck. Five bits.

The controller would act as a webserver over wifi, serving up the content of some pages on an SD card. It would also serve up the current duck state as JSON, and would accept POST requests with a querystring indicating what state it should put the ducks in.

The controller would respond to the interrupt by setting a volatile variable that would prompt it to refetch state from all ducks over i2c.

The webpages on the SD card would be some sort of HTML and javascript that talks to the controller and runs a game. I personally like angluarJS because I'm doing it at work. It would poll the controller for state - say - once a second.

Note that there's no security here - nothing to stop somene hacking the game over wi-fi. The simplest solution (apart from using a proper password on the wifi network) would be to have the controller arduino only accept connections from whitelisted IP addresses. Perhaps a password on the SD card allowing a connected client to grant/revoke access to IPs, and an admin URL. That way it's all on the SD card.

I hope you are getting a feel for what you are asking. What I'm describing here is what I think would be the easiest way to go about it. In the meantime, perhaps set your sights lower - two ducks might be do-able. One duck isn't enough, because for a proper PoC you need to cope with potentially multiple sources of impact.