Tips and Tricks for making the Helmets

[Crank729]

I'm surprised you don't have your own thread, threefn! You're helmet is amazing.

[ThreeFN]

I'm surprised you don't have your own thread, threefn! You're helmet is amazing.

I do actually , it's just over at Replica Prop Forum. I seem to date back to the days when all us helmet builders were sort of shooed into this tiny little corner of the forums. Perhaps times have changed, but I'm a creature of habit.

completely random here but how is your helmet coming along 3FN?

^this

EXCRUCIATINGLY slowly. The old work excuse gets old fast, even for my internal monologue. But seriously, we're a tiny company, and there are two guys right now who have to do two heavy duty R&D projects with the usual constraints: not enough time, not enough money, not enough people, not enough experience, etc, etc, etc. Hopefully it sucks more for me to not have time/energy to get stuff done that it does for you guys to wait in anticipation (but who am I kidding? )

So I'm trying something new, I like to call it SAD. Stands for Something A Day. I try to at least look at the code, drawings, spec sheets, etc every day. I normally get actual work, physical or code, done on the weekends, but during the week I've had the idea bouncing around in the head long enough to not be overwhelmed on the weekend.

So in the vein, on to what I'm doing now. I've decided to move to a new, totally integrated code base. Veterans (and experts) on my project know that I planned on using two microcontrollers (arduino based) to handle all the stuff my system does. One does the animations, the other does the UI and everything else, and simply tells the first one which animation to run. It's a complicated setup, has lead to plenty of annoyances, and uses up parts of the hardware that could be better left for other uses. With the faster, more powerful Arduino DUE on the way, it made sense to move to an integrated code base, where all code is run on a single controller. Enter threading.

Threading is the basis of the modern operating system. On a full blown computer, threading is how you can listen to itunes and browse the web at the same time. The application, such as the music player says to the OS "right, I'm a music player, and I need this much processing time at this interval so that the music doesn't skip". It also asks for RAM and such, but we'll skip that part.

In my application, I have several sub routines I want to run 'at the same time.' These include animations, the climate control, the heads up display, battery status, and so on. Each of those is basically a separate function. Obvious the animations take precedent, but the other functions have to happen eventually otherwise the user input whould never take effect, you wouldn't know you're low on battery, and you'd boil because the climate control hadn't kicked on.

I knew that I wanted something like threading to handle all these routines and make sure they would work together. I struggled with how best to implement the concept on my own, but the idea is challenging. Early ideas were that when the animation is in a 'waiting state' you would execute all the other routines. This doesn't really work because you want to be able to change the animation from inside one of those routines, that is now running inside the current animation. Basically, it's not going to happen that way.

Recently I stumbled across this threading library for arduino. It's a brilliant setup really. And it lets me accomplish what I want to do. Lets look at some code, a first for me on the forums:



In this block, I have a stand in for the 'change animation' code. In the real code this will done by interpreting button presses, but for now I just have a flip/flop in there that switches between two animations at 10 second intervals. and this is happening in a completely separate thread from the animation itself, which is the brilliance of the design.

It probably doesn't look like much, or look interesting, but this is an immensely powerful bit of code. It's as easy as 'killing' the current animation, and adding a new one to the main thread list when you want to change over. You can also add threads that only run once, such as static images, that kill themselves once they're done. There are also conditional threads that only run when certain conditions are met. For instance, there's no point in handling an animation change over if there hasn't been an input to do so.

Threads, being objects, also allow for you to 'partition up' the bits of code so that things are easier to read and debug. The animation that's running probably doesn't care what the helmet temperature is, and if it does, it can ask the climate control thread what the value is. In that situation, since you're not accessing the value directly, but asking the relevant thread, there's less chance of you screwing up that value by a typo in your code.

In the physical realm, I've gone through a few very rough prototypes of the new button gloves. These were pretty much wire jumper and rubber band affairs, and didn't last long enough to even take pictures. I'm returning to my original pair of gloves as the concept, except I'm using a more robust pair of gloves and some new stainless steel thread instead of the fraying silver coated nylon stuff. One of these weekends I'll stitch up a new prototype with those materials.

[Mr. Hoosteen]

I do actually , it's just over at Replica Prop Forum. I seem to date back to the days when all us helmet builders were sort of shooed into this tiny little corner of the forums. Perhaps times have changed, but I'm a creature of habit.



EXCRUCIATINGLY slowly. The old work excuse gets old fast, even for my internal monologue. But seriously, we're a tiny company, and there are two guys right now who have to do two heavy duty R&D projects with the usual constraints: not enough time, not enough money, not enough people, not enough experience, etc, etc, etc. Hopefully it sucks more for me to not have time/energy to get stuff done that it does for you guys to wait in anticipation (but who am I kidding? )

So I'm trying something new, I like to call it SAD. Stands for Something A Day. I try to at least look at the code, drawings, spec sheets, etc every day. I normally get actual work, physical or code, done on the weekends, but during the week I've had the idea bouncing around in the head long enough to not be overwhelmed on the weekend.

So in the vein, on to what I'm doing now. I've decided to move to a new, totally integrated code base. Veterans (and experts) on my project know that I planned on using two microcontrollers (arduino based) to handle all the stuff my system does. One does the animations, the other does the UI and everything else, and simply tells the first one which animation to run. It's a complicated setup, has lead to plenty of annoyances, and uses up parts of the hardware that could be better left for other uses. With the faster, more powerful Arduino DUE on the way, it made sense to move to an integrated code base, where all code is run on a single controller. Enter threading.

Threading is the basis of the modern operating system. On a full blown computer, threading is how you can listen to itunes and browse the web at the same time. The application, such as the music player says to the OS "right, I'm a music player, and I need this much processing time at this interval so that the music doesn't skip". It also asks for RAM and such, but we'll skip that part.

In my application, I have several sub routines I want to run 'at the same time.' These include animations, the climate control, the heads up display, battery status, and so on. Each of those is basically a separate function. Obvious the animations take precedent, but the other functions have to happen eventually otherwise the user input whould never take effect, you wouldn't know you're low on battery, and you'd boil because the climate control hadn't kicked on.

I knew that I wanted something like threading to handle all these routines and make sure they would work together. I struggled with how best to implement the concept on my own, but the idea is challenging. Early ideas were that when the animation is in a 'waiting state' you would execute all the other routines. This doesn't really work because you want to be able to change the animation from inside one of those routines, that is now running inside the current animation. Basically, it's not going to happen that way.

Recently I stumbled across this threading library for arduino. It's a brilliant setup really. And it lets me accomplish what I want to do. Lets look at some code, a first for me on the forums:



In this block, I have a stand in for the 'change animation' code. In the real code this will done by interpreting button presses, but for now I just have a flip/flop in there that switches between two animations at 10 second intervals. and this is happening in a completely separate thread from the animation itself, which is the brilliance of the design.

It probably doesn't look like much, or look interesting, but this is an immensely powerful bit of code. It's as easy as 'killing' the current animation, and adding a new one to the main thread list when you want to change over. You can also add threads that only run once, such as static images, that kill themselves once they're done. There are also conditional threads that only run when certain conditions are met. For instance, there's no point in handling an animation change over if there hasn't been an input to do so.

Threads, being objects, also allow for you to 'partition up' the bits of code so that things are easier to read and debug. The animation that's running probably doesn't care what the helmet temperature is, and if it does, it can ask the climate control thread what the value is. In that situation, since you're not accessing the value directly, but asking the relevant thread, there's less chance of you screwing up that value by a typo in your code.

In the physical realm, I've gone through a few very rough prototypes of the new button gloves. These were pretty much wire jumper and rubber band affairs, and didn't last long enough to even take pictures. I'm returning to my original pair of gloves as the concept, except I'm using a more robust pair of gloves and some new stainless steel thread instead of the fraying silver coated nylon stuff. One of these weekends I'll stitch up a new prototype with those materials.

if you make the thomas helmet with LEDs in them, make sure it has a smile for it to be an exact replica

[ThreeFN]

if you make the thomas helmet with LEDs in them, make sure it has a smile for it to be an exact replica

Rabid's group buy is made from my CAD model. Even though I took a lot of community feedback on that helmet, the design is ultimately my stylistic choices.

I never felt the smile worked with the helmet. The helmets are all fantastic radii and angles that result in brilliant reflection, shading and 'brightness'. I feel the small was too small and sharp to really compliment that overall look, it just looks too busy.

In the end, I'm very happy with this final product:

[Crank729]

Would it be too hard to get some more pics of your guy manuel 3d print? I have only seen the one pic from the front, do you think we could see the back and side profiles also???

[ThreeFN]

Would it be too hard to get some more pics of your guy manuel 3d print? I have only seen the one pic from the front, do you think we could see the back and side profiles also???

Have a glance through the photobucket.

[Crank729]

Sorry, hadn't seen those. That is a seriously impressive helmet. I am surprised more people haven't gone the 3d route.

[ThreeFN]

Sorry, hadn't seen those. That is a seriously impressive helmet. I am surprised more people haven't gone the 3d route.

Most people don't for two main reasons:

1) CAD skills. Trying to not be immodest, but I have 3.5 years of experience while I was at university and another 3 years professional experience. And for all 6.5 years of that I've been tinkering with a number of my own designs. And even with all that the GM and Thomas helmets were a challenge to create.

2) $$$$$. 3D printing is extremely expensive. Services like Shapeways have brought it into the realm of the 'common folk' but they base their business model on tons and tons of small parts packed into a single print run, so large parts are still about the same cost as the 'big guys.'

To my knowledge, there are only really 2 3D printed helmets (DP or otherwise) and both are my designs. I'm sure there are plenty of people who CAD a helmet then mill it or use pepakura (a few Iron Man builds spring to mind), but that demonstrates how expensive this 3D printed stuff is.

[Crank729]

Don't answer if you don't want to, but about how much did your guy man print cost?

[ThreeFN]

Don't answer if you don't want to, but about how much did your guy man print cost?

Well, I have a special arrangement right now for my main 3D printing supplies, but I won't get into that.

At one point I did price out a helmet through Shapeways. For 1/2 the helmet, at 1.5mm thick (would need serious reinforcement) it was $875 or there about. They've since changed the pricing model a bit, and this was probably 1-1.5 years ago.