Jump to content


Photo

Gun computer MkIV


46 replies to this topic

#26 Kingbob

Kingbob

    Member

  • Members
  • 133 posts

Posted 09 December 2016 - 10:25 PM

Installation update. 

Have installed most things on the left of the shell. The connector you see on the right is so it can plug into the other side of the blaster. Makes it easier when being assembled/disassembled all the time.

On this side are the mag size sensors, LCD screen, joystick, button, mag insertion switch, buzzer, and micro controller.

 

HF01.JPG

 

The outside. 

Bit hard to make out, but the white overlay lines up with panel lines on the shell so it looks at least sort of part of it. The large round black bit is the joystick, and little black button above it.

HF02.JPG


  • 0

#27 Kingbob

Kingbob

    Member

  • Members
  • 133 posts

Posted 10 December 2016 - 12:22 AM

Well the RPM counter is giving me grief. 

I'm using an IR LED/transistor pair attached to either side of a small hole in a flywheel, and at low RPM it does work, but as soon as it gets up to full speed it stops counting. I thought using a faster micro controller would solve it but no change.

 

I can think of 2 reasons why:

1: The output on the IR transistor cant change state fast enough to keep up with the pulses its getting.

2: At full speed the time that IR light is let through the hole in the flywheel is too small for the transistor to register it. 

 

I have some different IR transistors i'll test to see if any of them work better to solve option 1.

 

Only solution to option 2 i can think of is to elongate the hole in the flywheel so the IR light gets longer per RPM to register.

But i dont want to unbalance the flywheel  by removing too much plastic.

 

Anyone have any other suggestions?


  • 0

#28 Ming Batt

Ming Batt

    Member

  • Members
  • 12 posts

Posted 10 December 2016 - 01:32 AM

Well the RPM counter is giving me grief. 

I'm using an IR LED/transistor pair attached to either side of a small hole in a flywheel, and at low RPM it does work, but as soon as it gets up to full speed it stops counting. I thought using a faster micro controller would solve it but no change.

 

I can think of 2 reasons why:

1: The output on the IR transistor cant change state fast enough to keep up with the pulses its getting.

2: At full speed the time that IR light is let through the hole in the flywheel is too small for the transistor to register it. 

 

I have some different IR transistors i'll test to see if any of them work better to solve option 1.

 

Only solution to option 2 i can think of is to elongate the hole in the flywheel so the IR light gets longer per RPM to register.

But i dont want to unbalance the flywheel  by removing too much plastic.

 

Anyone have any other suggestions?

 

Your method of counting RPM should work.

A faster microcontroller shouldn't be necessary, as:

Let's just say, each motor spins at 100k rpm, for simplicity and its level of exessive-ness. Arduino Uno's clock speed = 16 mHz = 1,000,000 Hz. Motors spin at 100k rpm ~ 1,667 revolutions per second. Now, say that the motors are spinning completely asynchronously, which means that the microcontroller has to read ~3,200 times per second, which it is more than capable of; its clock speed is many order of magnitudes greater than the wheel's speed.

 

1. I can't speak for IR transistors, but I have some experience with photo transistors, and they were ridiculously fast, more than fast enough for an application like this, so assuming that IR transistors parallel photo transistors in speed, the IR transistor's problem with changing states shouldn't be an issue.

2. IR 'light's" amplitude is in the nanometers, a visible whole should be plenty big for IR light to pass through and be registered by the transistor.

 

If anything, it's the code. Make sure it's running at full efficiency (not like mine). You probably already know this, but use the interrupt functions instead of reading and checking the value, as they can run while other code is running too. This could be the case, but I highly doubt it. I'm pretty sure it's the code, as I was having similar problems with the mircocontroller seemingly not reading the values, but it turns out, I was having some code running at the wrong times, ultimately resulting in more latency between readings.


  • 0

#29 Kingbob

Kingbob

    Member

  • Members
  • 133 posts

Posted 10 December 2016 - 02:02 AM

Yeah i considered the code as well, which is why i stripped it back to a test sketch that does nothing but count the interrupts.

I'm only bothering to count 1 motor since they have the same power supply and are subject to the same braking from darts etc.

 

The M0 controller runs at 48Mhz, so shouldnt have any dramas, even assuming a high rpm count.

 

 

const byte interruptPin = 1;
int rpm=0;
int rpmcount=0;
int lastmillis=0;
 
void setup() {
  Serial.begin(9600);
  pinMode(interruptPin, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(interruptPin), rpmup, RISING);
}
 
void loop() {
  if (millis() > lastmillis + 250){ 
      detachInterrupt(digitalPinToInterrupt(interruptPin)); //Disable interrupt when calculating
      rpm = rpmcount*240;
      rpmcount = 0;
      lastmillis = millis();
      Serial.println(rpm);
      attachInterrupt(digitalPinToInterrupt(interruptPin), rpmup, RISING); //enable interrupt
   }
  
}
 
void rpmup() {
  rpmcount=rpmcount+1;
}

  • 0

#30 Ming Batt

Ming Batt

    Member

  • Members
  • 12 posts

Posted 10 December 2016 - 02:57 PM

Is your method working? From what I can see, it should be working perfectly fine.

 

First off, I see that you're using millis(). Millisecond = 1/1,000 of a second, maybe try mircos instead, although this shouldn't be a big issue, as long as your motors are clocked at under 1,000 revolutions per second, or 60,000 rpm.

 

Are you using an IR LED or laser? A laser is more precise and will work better as the sensor. IR sensors have different peak frequencies and wavelengths for maximum efficiency, so make sure you're in that range.

 

I was planning on using phototransistors on mine, so I was looking at this: http://www.johnloomi...nc/pt_char.html

"A phototransistor takes a certain amount of time to respond to sudden changes in light intensity. This response time is usually expressed by the rise time (tR) and fall time (tF) of the detector where:

... Phototransistors display tR and tF times in a range of 1 µsec to 10 µsec. "


 

tR - The time required for the output to rise from 10% to 90% of its on-state value.
tF - The time required for the output to fall from 90% to 10% of its on-state value.

I may be misunderstanding this, but even at 10 microseconds, the response time should be more than enough for reading the speed of the motor, in ideal circumstances. Although phototransistors won't have as much practical use in this application than IR transistors, due to the phototransistor's sensitivity to visible light, I would only assume that this speed is to apply to IR transistors as well.

 

Using the predetermined 100k rpm clock speed of the motor, equating to ~1.5k revolutions per second, the microcontroller would need to execute those 6 lines in the update function in 1/1.5 seconds, which it is more than capable of. You're calculating the speed 4 times per second, which should be perfectly fine.


  • 0

#31 Kingbob

Kingbob

    Member

  • Members
  • 133 posts

Posted 10 December 2016 - 09:24 PM

I'm using using millis to get the 4x/second calculation so when its working it will update the display 4x/second. Nothing to be gained by using micros.

 

I'm using an IR LED, which is matched to the IR transistor. (same manufacturer, same frequency etc). Too difficult to fit a laser diode in where I want it.

 

According to the datasheet for the transistor it has nice small trigger times as well, and even assuming a max speed of 30,000rpm, thats only 500/s, which both the transistor and microcontroller should be perfectly capable of handling. I made the hole in the flywheel longer so it has a greater period to detect the high of the LED per revolution, but that made no difference.

 

In theory, and by all the numbers, it SHOULD work! Thats why its so frustrating.

I'm going to go and buy a bunch of different IR transistors today from my local electronics shop, and try others. Maybe one will work.


  • 0

#32 Zack the Mack

Zack the Mack

    Member

  • Members
  • 360 posts

Posted 11 December 2016 - 12:38 PM

Hook an oscilloscope up across the phototransistor, run the motor full blast, and check out the amplitudes.

It's possible that the peak output voltage of the phototransistor isn't going over the microcontroller's minimum logic high voltage. If that's the case, you'll need to bias the transistor or amplify it with a fast transistor or logic buffer.

The opposite problem is possible too - at speed, the minimum output voltage might be too high to register as a logic low! If that's the case, you can use black paint or aluminum tape to block ambient light, and add a current-limiting resistor to dim the LED.

The important part is to use a scope and see the characteristics of the signal.
  • 0
Ask me questions about electronics, Arduino, and 3D printing

#33 truglodite

truglodite

    Member

  • Members
  • 8 posts

Posted 24 March 2017 - 08:48 PM

I might be able to add a muzzle velocity measurement as well. Use an IR sensor at each end of the barrel, and just measure the time between them breaking as the dart goes through.

Its a short barrel though, so may not be hugely accurate.

 

I'm also going to have another go at measuring the flywheel speed. I think the reason i had problems last time was simply the speed of the processor not being able to keep up with the interrupts from the sensor. The arduino nano i used has an atmega328 processor which runs at 16Mhz which isnt exactly zippy. This time i'm using a board with an ATSAMD21G18 ARM cortex M0 processor, which runs at 48Mhz. Hopefully this can keep up with the sensor. Also has an onboard JST power connector for a LiPo, and built in LiPo charger circuit if connected to USB.

And has way more flash and RAM which solves the graphics library issue i had previously.

 

I could add an ultrasonic sensor to the front, maybe tie it to a second screen on the top of the gun, do an Aliens style motion detector :D

16MHz 328's are plenty fast for even modded nerf... if you're picky just use direct port access (DDRD... PIND... etc) can get ~1usec response vs 40uSec digitalRead(). No need to wield the nasty Timer1 input capture methods, unless we're dealing with real guns.

 

I made my Nerf dart computer using a single IR sensor/emitter. Since all the darts are 2.75" long (pretty dang close), we can use the high-low-high time of a dart passing one sensor to find dart speed. I use direct port methods and I get good numbers from it. Most of the error comes from the few % differences in length from dart to dart. Of course I would have to code for cut down length darts... or add a menu item to select dart length... or design for sensors to detect length, LOL!

 

No matter how you go about it, having FPS #'s on the gun is fun! I coded to store dart fps and rpm data in an array as I fire. After the clip is empty it shows the average fps/rpm, and scrolls through fps & rpm for each individual dart. I have some ideas I'd like to try once my oled stuff arrives from China... I bet I'll find a good reason to tweak my code for ESP8266... and then I'll get my phone involved in the battles using the Blynk app.

 

Kevin

FPS is fun! I have my uC store dart fps and rpm data in an array as I fire. After the clip is empty it shows the average fps/rpm, and scrolls through fps & rpm for each individual dart. I have some other ideas I'd like to try once my oled stuff arrives from China.


  • 0

#34 aydensnake

aydensnake

    Member

  • Members
  • 50 posts

Posted 29 March 2017 - 10:07 AM

Any other suggestions for things to add in? The Hyperfire has a stack of room in the front end so I can fit all sorts of things in.

Yeah, get it to run doom


  • 0

#35 Silly

Silly

    Member

  • Members
  • 244 posts

Posted 29 March 2017 - 12:07 PM

Make a sound button connected to a speaker and an AUX cord so it can run music off your phone when you want.
  • 0

Co-Owner of the History of Nerf Modding research project, moderator of r/Nerf, owner of BlasterWiki, maker of 3d printed blasters (GitHub/Thingi) and Nerfy art.


#36 Ice Nine

Ice Nine

    Prince Dangus

  • Administrators
  • 1,460 posts

Posted 29 March 2017 - 02:08 PM

Yeah, get it to run doom

 

 

Make a sound button connected to a speaker and an AUX cord so it can run music off your phone when you want.

 

The next person to make an unproductive and unfunny suggestion in here gets suspended.


  • 0

Unholy Three: DUPLUM SCRTA, DUPLUM PROBLEMA (2009)

But Zeke guns tend to be like proofs by contradiction

Theoretically solid but actually non-constructive

Rnbw Cln


#37 SirBrass

SirBrass

    Member

  • Members
  • 74 posts

Posted 29 March 2017 - 06:43 PM

Do the old TI-82 middle school kid thing: install drug wars on it :-P

 

USER WAS SUSPENDED FOR THIS POST

WHAT DID I JUST SAY? TAKE SOME TIME OFF.


Edited by Ice Nine, 29 March 2017 - 10:59 PM.

  • 0

#38 Silly

Silly

    Member

  • Members
  • 244 posts

Posted 29 March 2017 - 07:08 PM

Could you put some kind of air pump in there and put an AT2k somewhere?

 

USER WAS GENTLY CHASTISED FOR THIS POST

THIS IS DUMB, BUT AT LEAST IT'S NOT WILLFULLY DISOBEDIENT.


Edited by Ice Nine, 29 March 2017 - 11:10 PM.

  • 0

Co-Owner of the History of Nerf Modding research project, moderator of r/Nerf, owner of BlasterWiki, maker of 3d printed blasters (GitHub/Thingi) and Nerfy art.


#39 SirBrass

SirBrass

    Member

  • Members
  • 74 posts

Posted 29 March 2017 - 09:53 PM

If you put in an ir led & ir photosensor to detect dart launch & put a small magnet near the trailing edge of the conveyor's edges (the two ridges which grab a dart & push it into the flywheels), you can get data about the conveyor's reliability in grabbing the darts, and about how many revolutions of the conveyor are needed per dart. Just use a hal-effect sensor near the flywheel entrance to detect when each ridge has traveled the length of the breach.
  • 0

#40 aydensnake

aydensnake

    Member

  • Members
  • 50 posts

Posted 30 March 2017 - 07:08 AM

 

 

 

The next person to make an unproductive and unfunny suggestion in here gets suspended.

Sorry, now for a serious suggestion. Since it's electronically stock then they should upgrade the motors and throw a lipo into this thing, I haven't modded an electronic blaster but I know those are some basic recommended mods for any electronic blaster


  • 0

#41 Kingbob

Kingbob

    Member

  • Members
  • 133 posts

Posted 01 April 2017 - 07:11 AM

The wiring has been upgraded and it will use a LiPo, but i havent yet replaced the motors.

 

I actually havent done anything on this in ages, have a new job and have been flat out. But yeah, some rather, umm, interesting ideas.


Edited by Kingbob, 01 April 2017 - 07:20 AM.

  • 0

#42 Kingbob

Kingbob

    Member

  • Members
  • 133 posts

Posted 23 May 2017 - 02:15 AM

OK so i had some wiring issues with how it was installed, was having nightmares with the screen, and getting the IR/RPM sensors working, so i ripped the whole thing apart and re-assembled it properly. Much neater now and no issues.

 

On the left side of the shell there is the 1.8" screen, joystick, reset button, mag insertion switch, mag size sensors, buzzer, level converter, and of course the arduino.

On the right side, are relay, voltage sensor, dart IR sensor, RPM IR sensor, and power supply. For now its running off standard alkalines, but have replaced all the wiring so it will be getting a LiPo shortly.

 

The code is about 85% done. At the moment its tweaking things like checking the mag size sensors are set to select properly, make sure all the magazine insertion stuff is in the right order, and that the screen updates properly when things happen. All the code is there, mostly just the order things happen.

 

There are 2 IR sensors in the barrel, one at the dart insertion point, one at the exit. By measuring the time it takes to get between them, it should give an approximate dart velocity. However when only measured across 10cm, it may not be wholly accurate, but it looks cool :)

The RPM sensor is also working properly now. On alkalines with stock motors it gets around 11-12k rpm. However i'm measuring every 250ms and multiplying it out, so again its not 100% accurate, but pretty close.

 

The gear going in the left side:

HF03.JPG

 

 

And the right side installed. The flywheel enclosure and flywheel got a quick spray of black paint to minimise any IR reflections.

HF04.JPG


  • 0

#43 Kingbob

Kingbob

    Member

  • Members
  • 133 posts

Posted 27 May 2017 - 05:09 AM

Got it all assembled today and started debugging. For the most part everything is working fine.

 

Have 2 issues:

I had set it up to measure the current draw of the whole system, but have discovered that sensor is only good up to about a 3A limit. I'm pretty sure the stock motors will exceed that even on alkalines, certainly when i put in a LiPo. I think i can rework it to be good up to 30A though, but need some components from ebay to do it so thats disabled for the moment.

 

Secondly, i had set it up to measure the speed of the dart. Had 2 IR sensors, one at the entry to the flywheel cage, other close to the tip of the barrel, with about 11cm between them. But ive found because of the rate of fire, it only works if i fire a single dart. Firing more than one results in the second dart triggering sensor 1, just before, or at the same time as, the first dart exits the barrel. This was messing up the calculations, either getting 0 speed, negative speed, or stupid speeds like 50m/s.

I might be able to get it to work by moving the first sensor to the exit of the flywheel cage, but it will reduce the distance and time between sensors, so may mean the result is less accurate, but will give it a go..


  • 0

#44 Kingbob

Kingbob

    Member

  • Members
  • 133 posts

Posted 27 May 2017 - 08:58 AM

Moved the IR sensor, but still a bust. They 2 sensors are just too close and the darts are moving too fast. 

At 5cm apart they register with zero millisecond difference. Would work on a longer barrel but at such a short distance theres just no difference in time to measure :(


  • 0

#45 Kingbob

Kingbob

    Member

  • Members
  • 133 posts

Posted 28 May 2017 - 03:46 AM

Well the blaster is finished. All the counting, battery measuring, dart firing detection, mag size detection, single/triple/auto firing all working. Turns off the motors (via relay) when out of ammo to save battery, and all working properly.

 

And i dont like it :(

 

The electronics i've put in all work fine, the problem is the belt dart feeding mechanism, its too imprecise. What i mean is, if i have it in single or triple shot mode, the motors get turned off after a single round, or three rounds. Then get turned back on once I release the trigger ready for the next shot. That all works, but the position of the belt and the nubs that grab a dart are too unpredictable. It can push another dart in before it turns off, or it half pushes a dart that enters the flywheel cage but doesnt shoot, but then when i fire next, i get 2 rounds or similar. I just cant think of a way around it.

 

In a Rapidstrike or something with a more controllable pusher mechanism it'd work fine, but this hyperfire belt drive mechanism just doesnt lend itself to controllable firing.


  • 0

#46 Meaker VI

Meaker VI

    Member

  • Moderators
  • 1,192 posts

Posted 28 May 2017 - 09:26 AM

...the problem is the belt dart feeding mechanism, its too imprecise. ...this hyperfire belt drive mechanism just doesnt lend itself to controllable firing.


There was much lamenting about this on Reddit. There are also a number of very capable electrical... people (? I don't know them so maybe they're not actually engineers?) who talk about things like live and dead open and closed centers. I have only a vague idea of what that all means, but it's possible someone has come up with/can come up with a switching arrangement that allows the HF to function in a reliable manner.


  • 0

#47 Kingbob

Kingbob

    Member

  • Members
  • 133 posts

Posted 28 May 2017 - 08:27 PM

Its a great setup for flinging darts in rapid succession, i'll give Hasbro that. But not for control.


  • 0


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users