An interesting data point on multi-stage flywheels

A few years ago, I wrote a post exploring the possibility of stacking flywheel cages to achieve higher velocities. This was written mostly from a theoretical perspective. At the time, there was very little actual data on how much velocity could be achieved with such systems - very few people had made multi-stage flywheel systems, and those had a pesudobarrel in the middle which dropped the velocities that could be attained well below the theoretical maximum.

As you might recall, the simple model that I used predicted that the glass ceiling velocity of such a system would be equal to the square root of the number of flywheel stages times the glass ceiling velocity of a single stage - and that the spacing between flywheels would have no effect on this velocity.

498 Nerf has obtained some very interesting results from a two-stage flywheel system with varying spacing between the stages. A video explaining these results, along with links to the chrono results, can be found here.

In summary, he obtained:

• 140 fps with the flywheel stages jammed as close as possible together
• 155 fps with the flywheel stages moved a bit further apart
• 165 fps with the flywheel stages spaced such that a dart enters one just as it leaves the other

All of these results were obtained with the same motors and voltage.

This last result is pretty close to what we should expect based on my model -  but the variation in velocity with flywheel spacing demands explanation. I can say that the explanation that 498 proposes is either incorrect or incomplete. While increasing the spacing between flywheels will result in the dart spending a greater total time in contact with at least one stage, it will also decrease the time that the dart spends in contact with both stages - and, mathematically, these effects should cancel.

Kysan 16180 motors running on 4S have a no-load speed of 22,200 RPM, and rhinos running on the same voltage have a no-load speed of 44,400 RPM, if we neglect energy lost due to air resistance on the flywheels assume a nominal voltage for the battery. These are greater by a comfortable margin than my calculated lower bounds on the critical RPM for each flywheel stage of 20,200 and 28,500 RPM for the first and second stage respectively. So, the numbers check out - it looks like 498's multi-stage flywheel system is supercritical, or at least pretty close.

However, the first flywheel stage has a free-running RPM that is less than the second-stage critical RPM - and I think that this is what explains the drop in velocity when the flywheels are spaced closely together. When the flywheels are spaced close together, the dart is accelerated by the second stage while it is still in contact with the first stage - and it is accelerated beyond the flywheel surface speed of the first stage. This results in the dart dragging the flywheels forwards instead of the flywheels dragging the dart forwards - hence the drop in velocity.

So: while these results may at first glance appear to contradict my model, they actually support it on closer examination. Given that the velocity attainable with a single flywheel stage is already pretty close to the maximum velocity that people outside of NIC wars usually want, this is largely just a matter of curiosity - but it's still nice to finally see some experimental verification.

Update: 498 has done some further experimentation, which provides more confirmation - his original setup, which had the motor cages right next to each other, yielded a higher velocity with first-stage motors with a higher RPM (Kysan 17114, which turn at about 30k RPM at 4S), indicating that his original first-stage motors were not supercritical.

Interestingly, he obtained an average of 152 or 160 fps (depending on whether a few shots, believed to be misread, are discarded), which is still less than the 165 fps that we would expect. Perhaps 30k RPM is still not quite supercritical - or perhaps the difference of ~5 fps in the average results is just an artifact of small sample sizes. Either way, these results strongly suggest that the 'dragging' effect is real.

808 Camera Setup, Mods And Trouble

First off, a bit more information on my 808 camera.

Here is where I got it: http://www.ebay.com/itm/262162917085

After some research, I think I can conclude quite definitely that what I have is not even a proper 808 type 18 V2 camera, it is a clone of some variety.

My camera does not have the same PCB layout as the known 18 cameras. The battery did not have a connector from the factory. It ignores the s1config.bin file which HETAI (the manufacturer of the real 18) describes in their documentation, and if its firmware even HAS the usual configuration options, I do not know what the filename or format are to use them. It reads the date/time and the timestamp on/off switch from a "time.TXT" file which is described in the user manual included. This is not an 18 camera feature, and is more common among older types of 808.

Nor does my camera pay any attention to the FWDVCH.bin file for firmware reflashing (I tried in an effort to resolve my bugs). Probably a good thing, because I don't know what the hell this hardware actually is, and it might not be compatible with 18 camera firmware.

The files this produces are 1920x1080, not 1280x720 as the real 18 should generate. These are almost certainly scaled from something (960x540? 1280x720?), I am just not sure what yet. The filenames are PICTnnnn.AVI which is once again unknown among the 18 cameras (should be PTDCnnnn.AVI or DCAMnnnn.AVI if I recall correctly).

The camera does not take still images if the shutter button is pressed either on standby or during recording. Another redflag.

Bugs  

Shortly after receiving this I discovered a number of issues:

• Occasionally, the camera starts itself back up repeatedly after being powered down manually or automatically.
• The camera often will not power back up after shutting down once. The battery must be disconnected or the reset switch pressed.
• Huge audio and video noise when battery voltage goes to around 3.6V
• File corruption.

I want to expand on the last: The camera splits files at 10 minutes like most 808 cameras do. However, on this unit, when the first file gets near 10 minutes, it seems to reliably have missing bits and audio sync problems. Furthermore these AVI files are structurally screwed up in some way and I am unsure about my success editing them with my present tools.

I tried to dashcam my drive to work several times and the files (all <10min after startup) were mangled.

The upshot was that successive files, including one that ran the full 10 minutes and overflowed into another, appear to be OK - so I should be able to limp this along by throwing away 10 minutes of dummy video at the start.

Research is ongoing and I hope I eventually end up with a fully working and configurable firmware in this thing.

Mods

The battery was an issue that needed addressing, of course. The little stock lipo was going to die quickly even if it worked. It also didn't seem to be in that great of health and wasn't holding a charge, who would have figured for a no-brand Chinese battery. So I did what I do best: Put a pack on it.

I had 2 of these Panasonic NCR18650B (3400mAh NCA) which have had their positive terminals smashed in from the defective contact design of Convoy flashlights (fixed in my light and my father's light by a mod). I didn't trust these to make reliable contact in the lights anymore and they were gathering dust so I welded tabs on one, wired and terminated with a Deans connector, and bam I have a mega ultra super high capacity battery for the 808, at a whopping 850% improvement over stock capacity. The camera itself lost its lipo and protection circuit* and gained a cable and a male Deans.

(* I didn't trust the protection circuit not to cause trouble, and the camera shuts down well ahead of the 2.5V cutoff voltage of the NCR cell, not to mention even the biggest supported card would fill up well before the battery was flat. So far I have run it about an hour equating to 8.5GB of files and the battery is only down to 4.06V.)

The way I run this (battery not quite properly secured in the hasty image):

It works out very well.

Stand by while I try to get some test footage of me driving up on youtube.

Edit: Test footage is up http://www.youtube.com/watch?v=fwESPiuBnk0

Edit 04-08-16: I seem to have discovered that this camera has, of all things, overtemp shutdown. Twice I tried to record dashcam videos with it today, and both times it cut out within a few minutes. I guess it didn't like being in a black plastic case attached to a black dashboard in the Florida sun. For how many things are missing or broken with this cam, that is a weird feature to have there and working. Cool?

As of right now it is recording continuously sitting indoors and will be doing so until the card is full, hopefully that is in fact what happened, and it didn't just randomly stop.

Also, a hunch that only the first file is corrupted no matter how LONG the first file is; so perhaps booting up and recording a 5 second dummy clip before filming anything will stop the initial wrecked AVI.

Conclusion

One, do not buy this camera. Do NOT buy this camera. Just don't. Feel free to buy an 808, but do yourself a favor and buy a genuine type 16 D-lens at around $40 - or even a genuine 18V2 from HETAI's ebay. This one I bought is a shitty clone and I regret buying it and am still concerned over whether I will be able to limp it along and get game footage out of it or if it will just fail miserably. Oh, and consider a Mobius rather than an 808, they are much more of a "real" piece of equipment. As soon as I can I will probably buy either a 16 or a Mobius.

Two, the hat mount works, and so does the battery.

Edit 04-15-16: A major update.

The planned combat test was a miserable failure and every single file generated of the entire TBNC woods game was junk. It's a shame too, although the game was a bit dysfunctional, some good moments and some chatting with players happened that would have made for a good first video.


It seems my hypothesis of first file corruption was false, something more entropic and devilish is at play here.


However I may have stumbled upon the answers from an unexpected direction, in the process of going through motions ruling out easy causes my attention turned to the flash card. A bit of digging turns up a lot about junk flash and junk SD cards that are frauds or don't meet specs. Great, I bought a cheapo "Infinitive" brand card, cheapskate I am.

So how do I verify SD card operation and performance? While researching that, I come across something from the SD group itself about specific low level formatting to ensure performance. Hmm, well when I started having power management issues, I promptly used newfs_msdos on my SD card for the same reasons, eliminate something wrong with the filesystem or fragmenting or whatever as a possible cause. That of course didn't achieve anything, but I didn't think anything of it at the time, because FAT is FAT is FAT, right? I reformatted right before the game and that was the worst it had ever been.


And now that I think of it, reformatting may have started my trouble with munched AVIs and missing data.



Now I have formatted my card with the "official" SDFormatter utility, and went through a few tests mounted on the dash of the suzuki. The files weren't mangled. All of them played, none of them was frame drop central, none of them had unsync'd audio and they obviously weren't (file length versus video runtime) missing huge data like before.



I am also keeping note of the battery voltage being near 3.8V at the time of this observation, in case I have a voltage related issue.


Fingers crossed that I managed to get a gremlin by the tail this time, because damn, the little camera works well when it works. I like it, I like it a lot. Even did some night driving with it and the footage wasn't a black abyss like some dashcam videos.

808 Camera and Preliminary Rig Plans

I have been looking to film gameplay for years. The trouble is, I am not going to spend $300 on a GoPro. That's a used transmission for my Suzuki, or a high-end superstock gun like a Tacmod, or a HPA rig - I am not spending that on a camera.

What I wanted was something as small and cheap as possible with a wide angle lens and acceptable resolution. Bonus points for no head straps.

I came across these 808 keychain cameras from the RC community and finally just bought one:

$29.12 shipped on ebay. This seems to be a type 18 with a wide angle lens assembly, a version I have not seen documented. It also doesn't use the same configuration file as the 18 camera people have seen. Still trying to figure that out so I can get some better settings.

You get the camera, a manual in Chinese and broken English, and the nonstandard USB cable. You must supply your own microSD card.

This thing is literally the size of a car remote lock keyfob and just as light.

With velcro:

And here's where this is going:

 

Tested and works great, not noticeable, doesn't make my hat fall off, not in my vision, perfectly aimed. No head straps, no mounts, no turning around my hat like basicnerf for a gopro.

The big issue with 808 cameras is that they are majorly janky. They can do the job, but the hardware is cheap, poorly assembled and usually includes low quality no-brand parts. The firmware can be buggy and half-baked. You can't expect the reliability of a GoPro.

I did already encounter some strange behavior (continually turning itself back on whenever a card was inserted) and lockups that seem to have self-resolved by simply letting it run and shut down automatically on its own, resulting in continued normal function. You have to get to know your 808 model and its quirks and how to dodge them.

When I had this open for inspection

Battery is a 400mAh lipo cell, that will need to be addressed before NvZ. In the meantime I may just strap my Miller single 18650 powerbank/charger to the back of my hat with a USB cable and a NCR18650B cell, if it works I will just keep the little lipo in there.

The video from this is decent. A bit noisy and artifactey as is the audio, but the lens is not bad at all, and it is 1280x720. Footage and more technical matters in the next post, and this setup should get field time and a youtube post next Saturday at TBNC.

Why spin-stabilized darts whirlybird so easily

Spin stabilization is one of the ways that the accuracy of Nerf darts can be improved. A spinning dart that would otherwise curve in flight - which happens due to damage or imperfect manufacturing tolerances - will instead travel in a corkscrew. The curvature of the dart's flight path is averaged out, and the overall path of the dart is a straight line.

Dr Snikkas' flywheel cages are a well-known way to put spin on a dart while firing it, and they do seem to improve the accuracy of people's blasters tremendously. The draugr team has been working on developing a mass-manufacturable flywheel cage that does the same, and, we've discovered something odd: spin stabilized darts whirlybird more. (A whirlybird is a complete destabilization of a dart characterized by the dart spinning rapidly like a pinwheel. A whirlybird can turn a shot that should have gone 100 feet into one that lands at your feet.) Sometimes a lot more: one of the test cages causes koosh darts to whirlybird almost all of the time.

Here are my (largely speculative) thoughts on why.

Edit: There was a mistake in my math in the first version of this post - this is what I get for working in a hurry and not double-checking.  It's fixed now.