Fully Automatic Dart Loader - Part 2

[@pb.projectbox]

If you're ready to learn more about math, programming, or science, visit brilliant.org/TheProjectBox/ to get a 30-day free trial and a 20% discount on the annual premium subscription!

[@kathrynelrod5570]

honestly i think the thing i’m most impressed with here is your skill with cardboard. that step feeder prototype is just gorgeous.

[@kristenmister3951]

Yeah, I'm personally doing a lot of cardboard DIY things with a few simple mechanisms but I'm really impressed with those prototypes especially how clear the cuts are. Nice job man ! The hole contraption is crazy ! Stay tuned for part 3.

[@PhantomMMIX]

This is the best over engineered thing I have ever seen I sharing it to all my friends your videos are amazing

[@Engineezy]

This geneva wheel quick return mechanism is SO sick!

[@drflux]

This project really tickles my brain! I cant wait to see it completed. It feels like your building a Nerf Sea-Wiz!

[@pulseworks1663]

absolutely insane for one person to do this much work

[@r3tep978]

you are probably my favourite creator right now, you give such a great insight into the process of making stuff like this.

[@ericlotze7724]

3:40 Had me scared for a bit there!

[@octavio2895]

Like others have suggested, I2C is very sensitive distances. You shouldn't route through cables more than a 20cm or so. An easy thing to try is to lower the clock speed of the I2C bus, it doesn't seem that you are in need of very high speeds anyway. You should make sure you have adequate pullups in the sda/scl lines, the value needed depends a lot on the number of slaves the current they can sink, experiment with a few values. Also make sure you are using the correct signal level for the I2c devices, 5V slaves might need a level shifter. Lastly, there are many poorly written drivers for arduino, if you have the code uploaded somewhere please share it.

[@paulroberto2286]

Hell yeah! Been waiting for this video! Happy new year as well!

[@endless_endeavors]

Yessss! I still can't wrap my head around all those indexing and timing mechanisms and how you put them all together. The flow of the new loader is definitely a huge improvement over the last design. Nice work!

[@gatlingtommy]

I understood the comment from last video a bit different, I thought he meant more like a single path for the darts for the complete loader, so from the hopper until blaster as a single path for the darts (you split up at the hopper to 10 and get to 1 dart as soon as they entered the belt). I think that kind of design might be a lot simpler, but probably not able to feed 5 darts per second. Also I really love your construction ❤! It uses a lot of cool mechanics and its mesmerizing to watch all that beauty working automatically! I want to see it finished 😊 P.S.: I am happy that my belt gave you some inspiration, so it proves the belt of the MOAB is useful for at least something (some people complain about my belt design)! 😉

[@coffeefish4743]

If your not one for sunk cost fallacy, you could try to replicate the vibratory bowl feeders already used in industry. They do the same thing (take bulk small objects, orient, and feed them one by one) and are already proven. If a single one is too slow you could use multiple small ones.

[@milesraftis5713]

this is sick

[@stratos2]

Glad to see you back! The entire time I was watching this video I felt like something was being overcomplicated for the problem that actually needs to be solved. I took the time of the video to think about it, and I think I have an idea: Remove the chain entirely and put a 10 to 1 hopper under the dart feeder. Then, adjust your dart holders to release the darts one at a time from left to right. If you leave enough distance between releases the darts should fall down the hopper and stack up after another. There is the risk of them bouncing on the walls, which could be mitigated with a steep enough hopper that perhaps has teflon siding for minimal friction. There may also be other solutions to this issue such as a track that moves to each sport with a servo, though this may have throughput limitations. Beyond that, to then turn your darts 90° or more, consider using a vinyl tube barely larger than the darts and feeding them through with compressed air. This should move the darts along nicely. Having air blow down the sides of the hopper may also help stabilize their path downwards. Another idea I just thought of would be redirecting the dart channels to a quarter circle or so and spinning a wheel with holes in it under them. The wheel would pick up the darts as it has spaces and then drop them downwards into a tube with compressed air. Have a look at what people building screw sorters and feeders have built, many similar problems of alignment and high feedrates have been solved before. While your systems seem really cool, my intuition keeps telling me that there must be a simpler way, that you're approaching individual local issues instead of questioning your design approach when things struggle. "When digging yourself into a hole, you should stop digging that hole, instead of inventing ways to dig said hole faster". All that said though, I appreciate being able to follow your progress and am always in awe of how much effort you're willing to pour into a project. I wish I had that amount of motivation.

[@generickwyjibo]

A lot of the complexity is coming from having 10 parallel streams in the sorter - I'm not sure why it couldn't just have a single feed out of the hopper in the first place.

[@mikeydk]

Oh man, what an epic side quest!

[@ericlotze7724]

This is such a cool project! Mixing a bunch of my favorite mechanisms into one thing!

[@bowieinc]

Your perseverance in astounding! I’m saving this to watch when I have project roadblocks.

[@MrGhotiol]

love this project. Adding a bevel to the casings of the chain might help the darts fall in a bit easier. Better yet just make them tapered all the way down, seeing as they don't need to be a tight fit until they are pushed out

[@tevincoburn1469]

23:50 I would suggest using a point distance sensor on one end (For example the right side) pointed towards the other (The Left) and then checking the distance value to see if it's clear. Or a beam break sensor. Beam break may be more reliable if you don't care about which dart is stuck. This would most likely be cheaper and require less compute as you would only need two sensors. If you do go with a beam break sensor (Basically a laser on one side and a photoresistor on the other) you could set it up as a binary input speeding up it's response time

[@ajmponchos3]

Love the project. The belt buffer is a stroke of genius, and it looks amazing! One suggestion: If I was you I would want to balance out some of that rotating mass. Building a stronger frame may alleviate the problem in the short term, but in such a precision mechanism I've gotta think that amount of shaking will eventually lead to tolerance issues. Your whole desk is moving haha. If you split the upper portion in half and mirrored it you could cancel all that momentum. Or don't split it in half and cheekily double the throughput. Anyway, cool stuff. Keep it up!

[@Thats_Mr_Random_Person_to_you]

Re: i2c i think 'some' of the glitching could just be down to the length of the wires. I've personally had this sort of 'intermittent' issue where a sensor random stops responding for a time and causes the whole i2c peripheral in the MCU to hang up when the cables are longer than is ideal. i2c is an amazing interface standard, but it was intended to only ever really be a communication protocol for relatively short inter-PCB style connections. Ie its not the most robust when you start thinking about the much higher impedance and inductance that longer and longer cables create. I appreciate this is somewhat anecdotal, but some of the odd behaviour might be the i2c peripheral itself getting hung up dueing a tx/rx glitch than longer cables can create, and chaining the bus to longer and longer lengths compounds that. Even the arduino i2c driver doesn't deal with all the very low level protocol stuff, thats handled at a hardware level inside the peripheral itself, so its very possible your code is not the issue at all and never was, nor the code of the arduino i2c driver, but maybe a timing glitch in the tx/rx steps that causes the i2c peripheral hardware to freak out and get into an invalid state (at the very low level i2c can be modelled as a finite state machine, a glitch could cause it to totall mess its state therefore breaking it until rebooted). You may just be reaching the limitations of i2c cable lengths (you could look at ways to tune the pull-up resistors values, or tune the impedance/inductance in other ways but that starts getting majorly complex quickly and might not actually help as it would introduce other issues). Solutions include: Reducing cable lengths If not possible maybe adding sensors of similar function to a seperate mcu that then passes the data via UART or other protocol designed for longer lenth cabling to the central controller (more complicated but can work well) Putting a scope on i2c bus and looking at options to tune the values of the bus pull-up resistors / other filtering to improve signal integrity Use a lower i2c speed if possible and see if that helps (usually you can choose between one or two i2c speed settings - ie clock rates).

[@jeroen94704]

+1 for this comment. Especially in a noisy EM environment with motors, running i2c over long wires is bound to hang up the bus at some point.

[@goodi2k7]

Usually when I2C gets stuck it is because of missing (or too many detected) clock pulses by the sensor due to noise on the signal lines. This causes the bus to get blocked by the sensor waiting for additional clock pulses. Usually the sensors don't have a timeout so the bus will never recover except after a reset. One possible trick to unblock the bus is to disable the I2C controller on the cpu and bit-bang out some additional clock pulses until the sensor releases the bus again.

[@pb.projectbox]

Thanks for the input! For my 200 dart per second blaster I was having issues with the I2C bus that I fixed with a LTC4311 active terminator. I tried the same thing on this project but it didn't help for some reason. I measured the I2C signal with an oscilloscope and it did look much better, but that didn't seem to be the issue. I'm leaning towards using a separate microcontrollers (connected through UART probably) for different areas of the system. I've got a bunch of different devices using the same I2C bus (2 variants of distance sensors, IO expander, magnetic encoder, OLED display) plus tons of tasks a single mcu has to juggle. Currently the way I'm thinking about splitting things up would basically have an mcu for each I2C device, so hopefully that will help with the issues.

[@ericlotze7724]

@JamesBruton dealt with this issue in Open Dog v1.0 too if i remember correctly so those videos/reaching out may help too

[@---..]

@@pb.projectbox The motors could be a source of noise. Twisting their power wires will help ensure the fields from the current in each direction cancels out. Also ensuring your sensor wires are nor run directly alongside the power wires for the motors could help. Given the sensor that seems to causer the most issues had the longest wires, this kind of noise seems a likely cause.

[@davidjennings2179]

The number of simultaneously moving parts in this is crazy! Love it though.

[@aL3891_]

This is so cool, amazing work!

[@tannerbuschman1]

Keep up the good work! this is really great engineering

[@louisbrill891]

I had those ID badge reels in middle school. You can increase the tension by opening them and adding a few more turns to the spring.

[@OZtwo]

very cool video. Can't wait until next one! Happy New Year all!!

[@Luzgar]

Why didn't you use one of those vibrating round bowl feeder that they use for feeding screws in a row in factories? It does pretty much the same thing as your machine, but is much simpler.

[@ericlotze7724]

This might be for interoperability of manual and automatic refilling. That or parts commonality. A bowl feeder may be nice though too!

[@pb.projectbox]

Short answer: I already had made a very effective shaker with a high output rate and wanted to keep using it. Long answer: Vibratory bowls require really solid bases, levelling, and are pretty noisy. They're also relatively expensive and making one with the tools I have access to would have been difficult. Plus I don't know how effective they'd be at moving darts (the heavy and sticky ends of the darts tend to make their movement unpredictable) at the rates I want them (>5 darts per second). Also figuring out how to load a moving chain was a very fun challenge.

[@ericlotze7724]

@ that buffer mechanism is used in industry for things like Film if i remember correctly so that was fascinating to see!

[@ericlotze7724]

This could be adapted to refill belts for Nerf Vulcan or that Gatling Blaster too which would be cool! (Granted as you pointed out airtight seal is harder to make with fits and tolerances required and whatnot)

[@CrzyMan_Personal]

Very exciting stuff! The dynamic accumulation to keep the slots in place is awesome. The geneva mechanism paired up with the offset intermittent gear was *chefs kiss*! While your current solution for distributing and indexing the darts is fairly compact, I can't help but feel like it must be a solved problem in the material handling world. My brain says we can probably leverage the fact that they want to roll, and that partially rolling might slightly reorient them. Vibratory tables aren't out of the question, but they can be a bit big. Maybe the step-lifter but with progressively narrower steps so the mis-oriented ones fall?.... How about a vortex chamber? I'm sure if we get them spinning, they'll prefer some orientation over another and then fall out?... okay, that one might be living up to my name a bit tooo much

[@vincentsoubbotin7830]

Great work, glad to have been able to give helpful feedback. I2c is very finnicky in my experience, you can try doing a timeout that cancels the reading if the device isn't responding but if you need that sensor for operation that isn't helpful. If you can find sensors that work via analog input, those are much easier and more reliable

[@alexgodin7867]

Just incredible.

[@Jardy0305]

I might have missed why you chose to use a sensor for each dart channel, as far as i can see it is only important to check if there is a dart stuck somewhere. Would'nt it be easier to use one laser and a photodiode on the ends of the channels? Just have one small hole lengthwise that the laser can shoot through. That way you can check for darts without having to use multiple sensors and reduce the wires / need for I2C. If you still want to check if each chainlink has a dart in it, shoot another laser from the bottom up through a piece of glass through the link to a photodiode.

[@pb.projectbox]

That's a good point. I really don't need to know which of the channels has a dart, so a single thru-beam sensor would simplify things. At least the analog to digital converters I'm using use SPI and not I2C. They've been incredibly reliable and haven't caused any issues. I do plan on adding sensors up higher to control when the shaker motor turns on. In this case I would need a sensor per channel, so maybe I can just move the sensors up a bit.

[@Enderbro3300]

i wanna use the dart sorter design and use it to load talon mags! i feel like thatd be pretty easy tbh

[@frollard]

problem with vl50l** sensors: The ones I have: They randomly just quit. I need to use the code to assign them all unique i2c addresses so they can share the bus. After a random amount of time, for a random reason (power bump? decoupling malarky? who knows) - they revert to the default address and have an address conflict. At that point, often the microcontroller freezes up because the bus doesn't respond in a valid way.

[@frollard]

Addendum: The solution is of course to do a heartbeat check of the reassigned addresses - I forget the exact default arduino library but if the default is 0x23, and you move them to 0x80, 0x81, 82, etc... then as a heartbeat check if you can get any data from 0x23. If you do, then re-run the i2c initialization and reprogram all the distance sensors.

[@pb.projectbox]

That heartbeat check and reinitialization is a good idea! I'll have to try that out.

[@ericlotze7724]

Anyone able to help with the code? I’m a similar hardware not software type but if anyone can would that help?

[@dpidcoe]

oh man this is so cool! I had the coilgun just a few booths down from you at the first opensauce and loved that first auto loading turret you had! Also, what you did with the belt links/sprocket/geneva drive/pusher mechanism is almost exactly what I'm trying to do with my coilgun right now to make it automatic (I also heavily borrowed from gattling tommy's design after talking to him at OS last year). Do you have any resources or tips for designing geneva mechanisms? I've got my sprocket and belt links working well enough, but there are so many variables that go into the geneva drive wheels that I'm struggling with where to even start.

[@pb.projectbox]

I remember your booth! The amount of thought put into the cooling and safety and every other part of your coilgun was impressive. Geneva wheels aren't too crazy to design. I made a somewhat parametric model of one a few years back where I would choose the drive pin diameter, the number of slots, and the radius of the wheel. Everything else is calculated from those. I don't remember exactly where I got the information to start, but I did just find this article that walks you through designing one: www.instructables.com/Make-Geneva-Wheels-of-Any-Size-in-a-Easier-Way/ Hope this helps!

[@Luzgar]

Did you know that for some reason, when KZbin decides to serve you the translated version of the title and description, there is no way of accessing the original ? Please, KZbin, just don't translate content that is in English. (And let me know when what I'm reading is a translation.)

[@kennedyhughes1394]

😮 👏🏻👏🏻👏🏻👏🏻

[@winorxp8952]

yeah i2c is hell sometimes. Often the librarys in Arduino have a timeout function if the device isnt detected and after it isnt detected once it will only detect the sensor after restart. i had built a tournament Soccer robot with i2c sensors (the gyro was a bbno055) and had often this Problem. As soon as the bno didnt worked, nothing worked. i would rather use "analog" sensors witch send pwm data which doesnt make any problems. Another solution would be if u used JST Connectors which was the solution for our gyro. the breadboard connectors u use can sometimes have a bad contact in a system with much movement, so they are literally deconnected for short periods of time. any other Type of pin connectors would work better, but i really love the JST XH connectors. Hope i could help, much love for such an amazing Project❤❤

[@pb.projectbox]

I haven't seen any time-of-flight distance sensors that don't exclusively use I2C, unfortunately. I'll definitely use better connectors, though. There are a lot of subpar connections between the sensors and Arduino with a crappy breadboard in the middle haha

[@williamschultz298]

For the alogrithm!

[@Don._Gabo]

4:33 name of software please

[@pb.projectbox]

Concepts! Very lovely vector based sketching software.

[@1978RSH]

by shaking the automatic loader faster than you did by hand, you give the darts to much upwards energy which prevents them from falling. Imagine a funnel with a pea in it, if you shake the funnel slowly the pea will circle it's way down the funnel, as you go faster you will at some point reach a speed where the pea will just roll around the funnel in a circle....or you might have heard of devil sticks??? It's the same effect.

[@wildgophers91]

Man I approach problems from the other end. Less hardware more software.

[@caylebray3894]

This is very cool! What cad software are you using?

[@creativecityis]

wait! how is he gonna stop that sledge hammer!!! ohhhh editing

[@drewk.8746]

Are the hexagonal shafts your using 8mm REX and are you using a sonic hub and other GoBilda or Servocity shafts and collars?

[@humanperson8418]

Don't let the monkeys get a hold of this!

[@srmofoable]

Does anyone know what that wire grid shelving stuff above the bench is called?

[@pb.projectbox]

It is called grid wall

[@droko9]

I'll be honest, I don't think this design will ever work reliably. There are too many moving parts, failure points, fine adjustments, you'll be chasing down problems forever. I think something like a vibrating bowl feeder will end up working a lot more reliably

[@SeanHilowwwwProductions]

how do you have time to do this?? are you doing this full time and how do you have the knowledge to do this, I want to know this because i want get mechanical engineering when I grow up.

[@karlohorcicka7388]

Why not just put laser and photodiode just above the cartriges? Then you have one beam and if no beam is detected, you have a dart sticking up. Same thing above darts. You have two sensors instead of 20

[@cadenmccorvey4153]

Great video and i love the use of mechanical design over programmable systems but why not use a vibratory sorter? Like one shown here kzbin.info/www/bejne/h3uag6VodqprgZY

[@pb.projectbox]

I'm glad you liked the video! I mainly skipped over vibratory feeders because I had already designed the shaker and knew that it worked very well. Vibratory feeders also need a super heavy base, need to be leveled, may not reach the feed rates I want (>5 darts per second), and are very noisy. I also just liked the challenge of loading a chain like this.

[@snowe..]

It seems like you took that commenter’s advice only partially. The entire bottom of the machine seems very over engineered. What is preventing just feeding out from your ten column mechanism in a slightly tilted fashion onto a conveyor belt. Conveyor belt transitions to one of those dual sided conveyor belts that squeeze the darts and then feed them in to the machine directly? As it is, the entire lower part of the machine still works in discrete steps, and thus isn’t continuous at all. It seems like the goal shouldn’t be doing things in steps, but instead doing it all at once.

[@zacharyreid7557]

only commenting because i cant hit the like button twice