Jump to content



Photo
* * * * * 3 votes

New DIY plunger design


  • Please log in to reply
734 replies to this topic

#1 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 17 July 2014 - 01:03 AM

For downloads and build instructions, please visit the main project page:  https://developer.mb..._Controller_V2/

 

I've been working on implementing what I think is a novel (and, if all goes well, really good) approach to analog plunger sensing.  I don't quite have it working to my satisfaction yet, but it's looking pretty promising, so I thought I'd share an outline of the design in case anyone else is interested in setting up the same kind of thing.  Be warned, it's most definitely not an off-the-shelf solution a la the VirtuaPin kit.  My approach requires some soldering and some custom mechanical work.  I'm going to open-source-ify the software and post the wiring diagrams once I have everything working properly, so anyone should be able to replicate it without any custom engineering work, but it most definitely won't be a plug-n-play kit.  

 

(It's also not a way to save money.  It'll run about $75 in parts if you count the plunger, so if you take into account the value of your time and the risk of breaking something in the assembly process, it's probably pricier than one of the commercial kits.  So why am I bothering?  Because of what I think will be superior performance.)

 

The key piece of equipment is something called a CCD linear sensor array.  This is basically like the image sensor element in a digital camera, but rather than arranging the pixels in a rectangular grid, they're all laid out in a single file.  (Well, okay, that's technically a special case of a rectangular grid. :))  There's a particular sensor available, the TAOS TSL 1410R, that's so uncannily perfect for this application that I have to think it was designed especially to be a pinball plunger sensor.  It's a single line of 1280 pixels at 400 dpi, which makes it 3.2 inches long - just a little bit more than the pull range of a standard pinball plunger.  The sensor is packaged on a little circuit board that's about 1 cm wide and just a little longer than the sensor element.  It runs about $35 and is readily available from electronics distributors on the web (e.g., mouser.com).

 

Here's what the sensor looks like.  The thin silver line in the middle is the glass window containing the pixel array.  There are 400 pixels per inch, so they're too small to see individually.  The gold bits are circuit board traces.  The 13 pads at the bottom are the terminals; you can see my elegantly soldered wiring already attached :)  I'd prefer to connect to it with some kind of pluggable edge connector, but it doesn't seem designed for this.  After extensive searching I couldn't find anything suitable, so I decided to just solder the wires.

 

taostls1410r.jpg

 

For deployment, the physical arrangement is that we mount the device above 5-10 mm above the plunger, with the image sensor facing down. As close as we can get it while assuring enough clearance so there's no physical contact.

 

Somewhere below the plunger we put a light source, facing up, so that it illuminates the sensor.  

 

The theory of operation is based on the idea that the plunger casts a shadow on the sensor in this arrangement.  When we read the sensor, we'll see darker pixels where the plunger is casting a shadow, and brighter pixels where it's not.  The position of the edge between bright and dark pixels tells us the current position of the plunger.

 

ccdinstalled1.jpg

 

ccdinstalled2.jpg

 

The thing I like about this approach is that it provides an absolute, high-resolution position reading.  All of the other approaches I've seen to this problem use some kind of relative position sensor - the VirtuaPin and NanoTech plungers use IR proximity sensors, and I've seen posts about DIY designs with mechanical potentiometers and linear induction sensors.  All of those give you a relative position.  The problem with relative positions is that the underlying physical quantities tend to have some variability separate from the thing you're trying to sense, which makes the relative sensing drift and wander over time.  The drift requires periodic recalibration, and the wandering requires degrading the resolution to reduce noise.  The existing solutions thus all seem to require fairly hefty trade-offs of reduced precision for increased stability.  With the linear sensor, in contrast, we're sensing an absolute position in space, because the pixels have fixed positions in space.  The physical setup is thus inherently immune to calibration drift.  In addition, the raw resolution of this device is so high that we should be able to get a really excellent signal/noise ratio.

 

How do we electrically interface the sensor to the computer?  Well, it's not something we can just hook up directly to a PC.  But it is perfectly suited for connecting any of the current crop of microcontrollers, such as Arduinos.  The one I'm using is a Freescale FRDM-KL25Z.  It's cheap ($12.99), fairly powerful, very integrated (e.g., it has on-board USB), and even has an on-board 3-axis accelerometer, which I'm going to use as an analog nudge device.  

 

Wiring: The TAOS sensor has 13 terminals.  A number of these can simply be wired together, so you end up with only 5 wires between the sensor and the microcontroller.  The KL25Z has integrated digital outs and analog ins, so it doesn't require any external hardware to interface the KL25Z and the TSL 1410R - you just connect wires directly between the appropriate 5 ports.  The KL25Z can also power the sensor, so there's no other wiring needed for the sensor besides these 5 connections to the KL25Z.

 

Interfacing to Visual Pinball: VP is set up to read an analog plunger via the joystick interface.  The KL25Z has an on-board USB port that lets it act like a USB HID (human interface device), so with the proper USB configuration reports we can make it look to Windows like a joystick.  Once that's in place, you just have to enable the analog inputs in the VP keyboard settings.

 

Software: I've written a first cut of the software, and I've just gotten to the point of installing the sensor in the cabinet to try it out under real-world conditions.  I was pretty thrilled to discover that it basically works, even in this preliminary setup.  Amazingly, the CCD array is so sensitive that it gets a usable signal from just the ambient light in the cabinet from the random little LEDs scattered around the interior (fans, USB devices, etc).  I haven't even installed a dedicated light source yet and it can already read the position with pretty good stability.  When I was in the planning stages, I figured I'd have to go to all sorts of lengths with shades and reflectors to get just the right lighting, but the sensor is so good that it looks like there'll be practically no special effort needed for lighting.

 

What's left to do: I'm getting pretty good position reports from the plunger, but the timing of the reports doesn't seem to work quite right with actual VP tables.  I've only just started playing with it in VP, so this might take some time to figure out.

 

I'm also sending accelerometer reports for analog nudging, and right now that part is a bit of a disaster.  It seems to be doing the right thing when I look at it in the joystick control panel, but it seems very bipolar in VP - I get either dead calm or VP thinks the cabinet is on a paint shaker, and there doesn't seem to be anything in between.  Not quite the subtle English I'm aiming for.  I'm hoping it's just a matter of tweaking the calibration parameters in VP.

 

At the moment, I think I have a pretty good proof of concept.  It'll definitely take some more work to make it real, so I'm not quite ready to post the software yet.  I'll certainly do that once I have it stable enough, but I'd be happy to send the working version to anyone who wants to try their own.

 


Edited by mjr, 09 June 2016 - 10:27 PM.


#2 maxxsinner

maxxsinner

    Enthusiast

  • Platinum Supporter
  • 319 posts
  • Location:Australia

  • Flag: Australia

  • Favorite Pinball: F14 Tomcat

Posted 17 July 2014 - 02:13 AM

Looks great mjr. Really thinking outside the box with this idea.



#3 boiydiego

boiydiego

    Pinball Fan

  • Members
  • PipPipPipPip
  • 978 posts
  • Location:baal

  • Flag: Belgium

  • Favorite Pinball: flinstones,t2 chrome edition,wcs,afm,fish tales,medieval,rollercoaster tycoon,taxi

Posted 17 July 2014 - 09:56 AM

indeed nice would like to see video of it in action !!


boiydiego___gebruik-n2kbkyc.png


#4 blur

blur

    Pinball Fan

  • VIP
  • 1,500 posts

  • Flag: Croatia

  • Favorite Pinball: Amazing Spiderman, Black Hole, Totem



Posted 17 July 2014 - 10:01 AM

Great solution!

 

BTW - how difficult it is to program that controller to work as joystick - with button contacts and acellerometer as yxz axis?

What would you need, some compiler, debuger, ... or you can just upload some code to controller and you're done (if code is good :))?



#5 Nemo

Nemo

    Pinball Fan

  • Platinum Supporter
  • 1,283 posts
  • Location:Netherlands

  • Flag: Netherlands

  • Favorite Pinball: Monster Bash

Posted 17 July 2014 - 10:30 AM

Hahaha you beat me to it ! I was experimenting with some linear CCD's salvaged from old flatbed scanners, i also am

using an Arduino for interfacing with the PC.

 

This project however has been set to the backburner for a while now, but your post has me re-think the project. I also ran

into the "wandering 0 point" issue, i had some code implemented to "zero" the array with each powercycle.

 

In a week or two i'll be enjoying a short vacation, maybe i'll pick things up where i left them.

 

 

Great post !


Gone fishin', no really.......

My F14 Cab http://www.vpforums....showtopic=21820

My Coffee Table http://www.vpforums....topic=25407&hl=

My Jukebox WIP http://www.vpforums....topic=23825&hl=


#6 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 17 July 2014 - 04:52 PM

BTW - how difficult it is to program that controller to work as joystick - with button contacts and acellerometer as yxz axis?

What would you need, some compiler, debuger, ... or you can just upload some code to controller and you're done (if code is good :))?

 

You do need a compiler, but there are a couple of free options.  Once you compile your code, you just download it to the card.  The card has two USB connections on-board - one that's for application use (e.g., for implementing a joystick), and the other that's for programming/debugging.  You transfer code via the programming port.  (Having the two physical ports is nice for debugging, because you don't have to unplug anything in the edit/compile/test cycle.  You can keep it plugged in on both ports at the same time.)

 

There are two free development platform options for the Freescale controllers.  One is a free version of Code Warrior that supports C (but not C++ - that's only available in a paid version) and uses code generation to help with the low-level hardware details.  The other is mbed.org, which is a completely on-line system that supports C++ and has a very nice class library that wraps the hardware components.  The CW system looks like it gives you more direct access to the bare metal, and it has an interactive debugger that runs over the programming port.  But it looks like it has a really steep learning curve to deal with the code generation scheme.  I'm using mbed, which has a practically zero learning curve and seems very capable.  Their class library doesn't give you direct access to some of the lower-level hardware details, but so far it seems to handle everything I've needed to do, and it appears that you can still bypass the libraries if you really have to.  Another great thing about mbed is that it has its own SourceForge-like repository of open source user code for supported devices that goes well beyond the official libraries.



#7 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 19 July 2014 - 12:11 AM

indeed nice would like to see video of it in action !!

 

Here you go:

 



#8 zebulon

zebulon

    Cantankerous old B****D

  • Platinum Supporter
  • 1,172 posts
  • Location:Whitby, Ontario, Canada

  • Flag: Canada

  • Favorite Pinball: xenon, Medieval Madness, Royal Flush, Silverball Mania

Posted 19 July 2014 - 03:00 AM

Very impressive...:)


 ZB%20%20Storefront1%20.png               [email protected]

Don't pm or expect an answer from me here ... the links above are my contacts.

I know so much about so little that I could teach you all there is to know about nothing......


#9 gigalula

gigalula

    Hummmm not sure yet :)

  • Platinum Supporter
  • 651 posts

  • Flag: Canada

  • Favorite Pinball: All of them from 70' to now. Even more with VP and FP :)

Posted 19 July 2014 - 04:21 AM

Wow ... really sensitive and looking so realistic



#10 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 22 July 2014 - 06:53 PM

A little progress update.  I installed one of the 3W RGB LEDs as the light source for the sensor, with all segments powered for white light, and it's way brighter than needed.  Putting a diffuser in the way makes it work, but I think I'm going to try some lower-power LEDs to see if I can titrate the ideal light source for it.  I expect the 20 mA type won't be quite enough light, but I'll start with a couple of those and see what kind of signal I get.

 

Some VP tables have animated plungers that work with this setup, and many other tables have animated plungers register the animation but won't launch the ball.  I haven't looked at the table scripts/settings yet, but having a couple of working tables should make it pretty easy to figure out.  I'll try to document the procedure for tweaking a table to make the plunger work with this device.

 

I'm making progress on the nudging.  I've refined the device-side software, and I've also found some small changes to the VP software that seem to greatly improve realism.  It's close to actually feeling realistic, but it's not quite there yet, so I'm still working on it.  If I can get it working well enough, I'll see how the VP developers would feel about incorporating my VP-side changes into the mainline - I think they'd benefit physical accelerometer handling in general.



#11 blashyrk

blashyrk

    Pinball Fan

  • Members
  • PipPipPipPip
  • 549 posts
  • Location:Norway

  • Flag: Norway

  • Favorite Pinball: Attack from Mars, Medieval Madness, White Water

  • PS3 Gamer Tag: Blashyrk

Posted 22 July 2014 - 07:10 PM

Nice work mjr :) Looks very promising

#12 jkimbrell

jkimbrell

    Enthusiast

  • Members
  • PipPipPip
  • 298 posts
  • Location:Cincinnati, OH

  • Flag: United States of America

  • Favorite Pinball: Star Trek NG, Indiana Jones, South Park

Posted 26 July 2014 - 12:22 AM

very impressive work!  Please keep us posted



#13 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 26 July 2014 - 01:12 AM

Thanks for all the supportive comments!

 

I got sidetracked for a couple of days tracking down some issues with the low-level USB code in the mbed library (mbed is the development platform I'm using for the microcontroller software).  I managed to fix the problems, so I'm back to working on the pinball aspects of the code again.

 

I tried wiring up a set of 5 small blue LEDs (the standard through-hole 20mA type) as the new light source for the plunger sensor, thinking that they're so tiny that I'd need a whole bunch to get enough light.  The sensor surprised me yet again with its amazing night vision powers.  5 of the LEDs is too much light.  It looks like 2 is the magic number, at about 8" away.

 

Nudge handling is still in progress.  I've come up with an algorithm that looks promising, but it'll take a couple of days to implement and test.  If I can get it working well enough I'll post another video of that.  Plus, that should just about wrap up the project, so I'll get to work writing up documentation at that point.



#14 blur

blur

    Pinball Fan

  • VIP
  • 1,500 posts

  • Flag: Croatia

  • Favorite Pinball: Amazing Spiderman, Black Hole, Totem



Posted 28 July 2014 - 02:06 PM

maybe you should say what are you changing in nudge algorithm before you do it, just to be sure you are changing something meaningful.

 

lots of people are not happy with physical nudge but most of the problems comes from the fact that nudge algorithm only detects what is really physically going with table and applies it to the ball - meaning it is real.

 

some of these reality problems are:

hard to nudge - cause it is hard to nudge big physical pinball (or you might have calibration problems)

some strange recoil after nudge - because physically table really bounces back after nudge - controller only detects it

strange directions - you hit table from left, ball goes to the left, you hit it from front ball goes down - these are real world directions that the ball goes, not up and not right.

some people think recoil should be implemented after analog nudge also - there is no need for that, if table will recoil that recoil will be detected - no need to simulate it

...


Edited by blur, 28 July 2014 - 02:09 PM.


#15 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 28 July 2014 - 05:48 PM

maybe you should say what are you changing in nudge algorithm before you do it, just to be sure you are changing something meaningful....

 

lots of people are not happy with physical nudge but most of the problems comes from the fact that nudge algorithm only detects what is really physically going with table and applies it to the ball - meaning it is real.

 

some of these reality problems are:

hard to nudge - cause it is hard to nudge big physical pinball (or you might have calibration problems)

some strange recoil after nudge - because physically table really bounces back after nudge - controller only detects it

strange directions - you hit table from left, ball goes to the left, you hit it from front ball goes down - these are real world directions that the ball goes, not up and not right.

some people think recoil should be implemented after analog nudge also - there is no need for that, if table will recoil that recoil will be detected - no need to simulate it

 

I'm with you on all that.  I've got a couple of real machines, so I'm pretty familiar with how the real thing behaves.  And I can look at it side by side with the simulation.  I'm pretty picky about verisimilitude on this project - I'm not going for some kind of cartoonish effect.  All I want is for the ball to behave exactly like the real thing. :)

 

*In principal*, you should just be able to feed the raw accelerometer data into VP and get good results, because as you say, the accelerometer readings should tell you what's happening with the real cabinet motion.  I was actually kind of surprised when I first got this hooked up and found that it didn't quite work that way.  Looking at data streams from the accelerometer explained it, though.  These MEMS accelerometers are just not very accurate - they're noisy, they're imprecise, and they have a finite sampling rate that makes them miss the high-frequency components of a non-smooth acceleration (nudges are quite the opposite of smooth).  Accelerometer data has measurement error that's fairly substantial on the time and spatial scales we need for nudge simulation in VP.  (This isn't a problem with the particular device I'm using, by the way - it seems to be performing to spec.  It's just the nature of this class of device.)

 

If I'm successful, the results will speak for themselves.  If not, I can always fall back on the raw accelerometer data.  And anyone who wants to use the software can always disable my special processing if they don't like the effect, since the software will be open source.



#16 blur

blur

    Pinball Fan

  • VIP
  • 1,500 posts

  • Flag: Croatia

  • Favorite Pinball: Amazing Spiderman, Black Hole, Totem



Posted 29 July 2014 - 01:45 PM

a, so you don't change any code in vp that is executed on nudge - you are trying to filter data that comes from accelerometer.

 

this class of the device problem could be the problem on nanotech nudge detector also so it would benefit from fixing that raw data flow that comes from device

 

BTW i had some idea about some completely simple and bullet proof analog nudge system that would be inuitive and would not need any calibration - ever, and wouldn't have noise

 

idea is this - you make lockdown bar moveable in all directions with some springs (actually you have to move only from left, right and the front) - you put a gamepad stick under lockdown bar - so gamepad is fixed to the case and lockdown bar moves joystick around - so in zero position stick is at the center, when you hit lockdown bar from either side stick moves, and springs return it back

you can even nudge in any direction, diagonal for example

 

and you will never move complete pinball (some people had to stop nudging because from all nudging backglass casing would break and fall of)


Edited by blur, 29 July 2014 - 01:50 PM.


#17 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 02 August 2014 - 12:29 AM

I finally have the nudging working about right.  I ended up having to add the new logic to Visual Pinball itself.  I was hoping to have it all on the device, but that turned out not to be workable because of the nature of the joystick interface.

 

Here's a little video demonstration:

 

 

Some details on the theory of operation...

 

The basic problem I've been trying to fix is residual velocity from nudges that don't cause collisions.  In the unmodified VP, if you fire up a zero-slope table and drop the ball somewhere in the middle away from any obstacles, then you give the table a nudge, it will almost always impart a little velocity to the ball.  If you keep nudging at the right frequency, you can add a little more velocity, and a little more, etc, until the ball is really moving.  If you do the same thing with a real pinball on a flat surface, it's very difficult to get it moving just by nudging the surface.  

 

In real life, a nudge momentarily displaces a table from its rest position, but the cabinet immediately rebounds, and quickly stops at the same place it started.  (Assuming you didn't knock it hard enough to make it skid across the floor - hard to do with a real 400 lb pinball cabinet.)  It might sway back and forth a few times as the energy from the nudge damps out, but in the end the cabinet ends up where it started.  

 

If we think about the problem in terms of dead reckoning the cabinet's position in space using the accelerometer data,, we should always find that we're back where we started once a nudge has settled out.  Or, put another way, we should find that the velocities over the course of a cancel out - we start at rest and end at rest.

 

The code I added to VP essentially keeps track of the total velocity implied by the series of accelerations read from the accelerometer, and over a short time window,tries to make sure they net out to zero.  It doesn't just cancel every acceleration immediately, of course - that would make nudging do nothing at all.  Instead, it watches for signs that the real accelerations are damping out on their own, and inserts adjustments into the data to make sure they cancel exactly.  

 

It also recognizes continuous accelerations - not transient spikes, but long-lasting one-way accelerations.  Barring unusual situations (say, the cabinet is on board an airplane that's accelerating down the runway), a long-lasting acceleration has to be from gravity, so it signifies that the player has picked up one end of the cabinet and is holding it at an angle.  You actually do want a residual velocity in such a situation, so the code doesn't cancel these.

 

One way you could look at the code is that it implements a very simplistic physics model of the cabinet, and tries to reconcile the ideal behavior of the model with the real acceleration data.  I actually spent a while formally modeling the cabinet as a forced damped oscillator, but I eventually discarded that approach as too complicated and too constrained.  (For one thing, it can't handle the inclined cabinet situation.)  The final design is ad hoc, and doesn't have a formal physics model, but it still has some of the same features conceptually - a damping function is a key element, for example.

 

Current status:

 

I think the code is working pretty nicely at this point.   The caveat is that I've mostly played with it in unrealistic test conditions - with the accelerometer out of the cabinet and on my desktop, and using contrived tables, mostly an empty zero-slope table.  I think the zero-slope table is the most rigorous possible test environment for nudging, because nudging is the only force that affects the ball in that setup.  Any anomalies or artifacts are immediately exposed, because there are no other interactions to blame.  So I'm not too worried about how it'll behave in real tables - they'll only be more forgiving.  The thing I'm going to have to spend more time assessing is the behavior with it actually installed in the cabinet.  It seems pretty good as it is, but I wouldn't be surprised if spending more time with it makes me want to adjust some of the parameters a bit.

 

Anyway, I'll spend some time with it in the cabinet and do some tuning as needed.  Assuming I continue to be happy with it, I'll get in touch with the VP developers to see if they want to add it to the base code.  There's nothing special in it for my accelerometer, so I think anyone with an analog nudge setup could benefit from it.  Plus the changes are very isolated, so I think there's no risk in adding it to the base code as long as it's controlled by an option setting.  But if they're not interested, I'll certainly be happy to provide it as a source code patch that anyone can apply.

 

I mentioned at the top that putting the code on the device turned out to be unworkable.  In case you were wondering, here's why.  The basic thing that we're trying to do is to get the series of accelerations seen by VP to net out to exactly zero over the course of a nudge.  To do that we have to know exactly what accelerations VP sees.  Initially, I naively thought that the joystick updates sent from the device correlated one-to-one with what VP sees.  But this isn't so.  For one thing, the joystick interface is conceptually a polling type of interface.  From the computer's perspective, a joystick is a continuous analog device - it's not like a keyboard where each key press is a discrete event and you need to capture each event individually.  If you move a joystick from point A to point B, it's not practical to report every fraction of a millimeter along the way as a separate event.  Instead, the computer just checks in once in a while to see where the joystick is.  This alone makes it impossible for software on the device side of a joystick interface to communicate an exact series of data points to the host.  The device can post all of the discrete updates it wants, but the computer might only sample a few of them and ignore the rest.  If that weren't enough, there's also a separate complication in VP itself.  VP reads input at its own convenience, and the device can't determine when VP is going to read a sample.  So the device could adjust its reports so that the accelerations net to zero, but VP would still get a non-zero net velocity out of it, because it doesn't apply each reported acceleration for the same amount of time.  

 

That's why this code has to be in VP.  It incidentally is also a significant part of why the code is needed in the first place.  Part of the reason we need the correction is that the raw accelerometer measurements aren't perfect - if you look at the raw data for a nudge, the numbers will come really close to canceling out, but won't get there exactly.  The device just can't be expected to get an exact reading on every sample, and it only takes samples a few hundred times a second, so it might miss some short spikes.  But even if the accelerometer readings were perfect, there'd *still* be data loss due to the joystick and VP timing issues.  Lost updates through the joystick interface might even be a more significant source of error than accelerometer noise, from what I observed when testing.

 

This is almost the last step with the overall project before documenting it.  I still have to get back to the plunger and get that working to my satisfaction with real tables.


Edited by mjr, 02 August 2014 - 12:35 AM.


#18 sliderpoint

sliderpoint

    Pinball Fan

  • Members
  • PipPipPipPip
  • 760 posts
  • Location:Spokane, WA

  • Flag: United States of America

  • Favorite Pinball: Metallica

Posted 02 August 2014 - 04:03 AM

Which version of vp have you been testing with? Have you tried your code additions to the physmod version? Does it result with the same behavior? This seems really great and would love to test it out with the analog device I have.

-Mike

#19 jkimbrell

jkimbrell

    Enthusiast

  • Members
  • PipPipPip
  • 298 posts
  • Location:Cincinnati, OH

  • Flag: United States of America

  • Favorite Pinball: Star Trek NG, Indiana Jones, South Park

Posted 02 August 2014 - 06:38 PM

That nudging action looks so good that I think I should just toss my Sidewinder into the trash! Since I don't plan to add an actual plunger to my setup, would your code, once released, work to allow nudging with the Freescale FRDM-KL25Z?  If understand your first post correctly, the CCD sensor relates only to the analog plunger and the nudging is all happening from the Freescale device.. is that correct?  Very impressed!!   :love39:  :love39:


Edited by jkimbrell, 02 August 2014 - 06:41 PM.


#20 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 02 August 2014 - 07:13 PM

Which version of vp have you been testing with? Have you tried your code additions to the physmod version? Does it result with the same behavior? This seems really great and would love to test it out with the analog device I have.

 

I've been working with the 9.9 branch, but I looked at the latest trunk version a few weeks ago, and it looked like there are no changes in any of the nudging code.  It looks the same in the older branches as well - I don't think this code has been touched in quite a while.  So I think you could use the new code in any recent VP branch without any changes.


That nudging action looks so good that I think I should just toss my Sidewinder into the trash! Since I don't plan to add an actual plunger to my setup, would your code, once released, work to allow nudging with the Freescale FRDM-KL25Z?  If understand your first post correctly, the CCD sensor relates only to the analog plunger and the nudging is all happening from the Freescale device.. is that correct?  Very impressed!!   :love39:  :love39:

 

Thanks! :)

 

You're correct on all of the above.  The code works fine even if the CCD isn't attached - it just sees random floating voltages on the analog input that's assigned to the CCD.  It would also be easy to just remove the CCD code entirely, which would speed up the sampling rate for the accelerometer - it takes about 25 ms (in my current code) to read the CCD, so you get about a 50 Hz update rate.  The update rate would probably go above 100 Hz if you bypassed the CCD reads.  I'm not sure that would make a perceptible difference, since I'm already reading the accelerometer at 800 Hz and averaging the samples over the USB update interval, but faster is always better when iit comes to gaming.  :)

 

The VP changes should work with any accelerometer, by the way, so you might want to try them with your existing setup to see if they help.  If not, the Freescale is a cheap alternative.

 

By the way, I spent a while last night playing with the new setup in the cabinet using real tables (real virtual tables, that is, as opposed to empty test tables).  So far so good.  The effect on real tables was noticeable but subtle.  The reaction seems to be nicely linear with the force of the nudge, and I didn't see anything anomalous.


Edited by mjr, 02 August 2014 - 07:22 PM.