The Iron Girl Project - Computerized Exoskeleton System

Ah, I couldn't find any "JORDY" units on Ebay. Got any links?

I do like your blast for the repulsar more than my own. What are you doing? Just taking the brightness from your min value to the max and backing it down? What are your min and max values for brightness?

As far as audio....my Raspberry Pi is actually only doing 1 thing with audio. Playing theme song music from some embedded speakers in my chest.
All my other sounds are actually going to be from seperate, local speakers and from a small 'audio recording/playback' board that can be 'triggered' to play a sound. So when I fire my repulsar, it will fire the neopixels while also sending a signal to the playback board for it to fire, and the speaker will be located near where the action happens (hands, or chest, whatever). This eliminates the needs for the Raspberry Pi to worry about any lag or anything. These boards can be had for cheap, usually between $5 to $10 each on ebay or on Amazon. They're great for this kind of situation because they're low power, and they output right to a speaker. This way the arduino can just send a positive trigger to the board and it fires off the sound. Simple, but very easy and effective.
 
Ah, I couldn't find any "JORDY" units on Ebay. Got any links?

I do like your blast for the repulsar more than my own. What are you doing? Just taking the brightness from your min value to the max and backing it down? What are your min and max values for brightness?

As far as audio....my Raspberry Pi is actually only doing 1 thing with audio. Playing theme song music from some embedded speakers in my chest.
All my other sounds are actually going to be from seperate, local speakers and from a small 'audio recording/playback' board that can be 'triggered' to play a sound. So when I fire my repulsar, it will fire the neopixels while also sending a signal to the playback board for it to fire, and the speaker will be located near where the action happens (hands, or chest, whatever). This eliminates the needs for the Raspberry Pi to worry about any lag or anything. These boards can be had for cheap, usually between $5 to $10 each on ebay or on Amazon. They're great for this kind of situation because they're low power, and they output right to a speaker. This way the arduino can just send a positive trigger to the board and it fires off the sound. Simple, but very easy and effective.

Well, I couldn't find any current auctions for super-cheap, but this one is 135. Adding "Enahcned Vision" to the search might also help. There's always a bunch for around 500, but I've seen them go for as low as 50 for a full used set. Also, any auction for the Olympus Eye-Trek FMD-700.

Yup, I'm doing a "warm-up" pattern to 20 brightness, then spiking to 255, delaying 100ms, then fading back to 20 with a 2ms delay for each step. My code's attached, although it's for a Trinket. The center 3W LED is a bit dim because my MOSFET's gate is too high for 3.3V logic, but it works for now, and I'll change it out at some point. I tried using a TIP120 (Darlington), but the voltage drop was too much and it wouldn't light up nearly at all.

I like the idea of the speakers being located closer to the source of the action, would go over better when walking around a con. I've also seen those audio boards around, but I figured I'd add in that data to the RPi to handle since I wanted something to show for all the I2C work, I guess. *shrug* Mrow.

~Lexikitty
 

Attachments

  • Repulsor_Ring_RH_v3_2a1.zip
    1.2 KB · Views: 118
I'll let you know in the next few days how the individual board thing goes. I just got 3 of them in the mail and I'll be testing them out soon enough.

As for the MOSFET, I assume you're using them with the source tied to ground? How much is the average current when it's just sitting there lit? You should be able to use some rather small FET and accomplish the task.
Invalid Request

That should work very well I would think for your application. If the SOT-23 package is too small, I'm sure you can find similar parts in a TO type package as well. That part is also rated for use on Logic Levels down to 2.5V I believe.

Another thing you could do is to throw a buffer (or 4) between the gate and the RPi, which will give you even higher current output to forcefully drive the gate of the FET. That's pretty standard in the electronics world to be honest, and I've done it a number of times.

Anyway...I'll look into those glasses. Do they adjust the distance between each lens? Currently, a friend had a Vuzix Wrap310 pair that look very similar, and I couldn't use them because the eyes were too close together and I couldn't focus on them properly.
 
I'll let you know in the next few days how the individual board thing goes. I just got 3 of them in the mail and I'll be testing them out soon enough.

As for the MOSFET, I assume you're using them with the source tied to ground? How much is the average current when it's just sitting there lit? You should be able to use some rather small FET and accomplish the task.
Invalid Request

That should work very well I would think for your application. If the SOT-23 package is too small, I'm sure you can find similar parts in a TO type package as well. That part is also rated for use on Logic Levels down to 2.5V I believe.

Another thing you could do is to throw a buffer (or 4) between the gate and the RPi, which will give you even higher current output to forcefully drive the gate of the FET. That's pretty standard in the electronics world to be honest, and I've done it a number of times.

Anyway...I'll look into those glasses. Do they adjust the distance between each lens? Currently, a friend had a Vuzix Wrap310 pair that look very similar, and I couldn't use them because the eyes were too close together and I couldn't focus on them properly.


Thanks for the FET advice. I'll have to ask my girlfriend, (who does all the soldering in exchange for Starbucks, due to my defective eyeballs), if she'd be up for some SMT work, but the TO/any DIP packages would probably be preferable, since I already have most of this almost finished on a DIP protoboard. The source is tied to ground, if I remember correctly from here at work, and the logic's coming out of the 3.3V Trinket actually, not the RPi itself. Forward current along the LED is about 350mA@3V when on. I hadn't thought of a buffer - I'm assuming you're referring to a voltage buffer amp, to increase the signal to the gate? - but I'll see if I can find one or throw one together sometime this week.

Ah, found a diagram on my blog. Glad it's here to remind me of things I don't, lol. The only thing it's missing is the signal wire to the NP Ring...must have forgotten that.

Trinket_Repulsor_v0-3a_img1.png

The JORDY/FMD-700 glasses don't adjust the distance between the eyes/across the bridge, but they do sit back from your face a bit farther than most, and are designed to be worn with standard prescription glasses underneath (that's how I always used them). Although the more I build up the HUD, the more I'm dreaming about a nicer 720P HMD. Depends on how the graphs turn out.

Speaking of the HUD, here's an update using the sketch I made earlier, if anybody's interested.

HUD_G_Blue.png

On an unrelated note, it feels refreshing as hell to finally geek out on this project. This stuff had gone way over the heads of even my most techy friends, and even most of my coworkers. Gets me all re-energized. :)

Cheers,
~Lexikitty
 
Last edited:
If you use a buffer, for instance an AND gate that has both inputs (A and B) tied to the output of the Trinket, and put 4 of them together (a QUAD AND gate part, with all the inputs tied together, and all the outputs tied together) you should easily be able to drive any logic level MOSFET out there. The real issue is putting enough current into the gate of the FET to cause it to change state. The more capacitance the gate has, the more current needed to switch it quickly. It's just one way of dealing with the issue.

Other than that, everything looks good. I'm kinda surprised that you used a single large LED for the center, instead of just a single NEOPIXEL. You could then have them all change colors. (That's just what I did, and was just wondering)

The HUD isn't looking bad. The biggest issue I would see is making the altitude and everything show up properly.

Have you seen this?
Jayse Hansen Portfolio | Iron Man's Mark VII HUD | Jayse Hansen Portfolio |

This is the gentleman that designed the HUD for Iron Man in Avengers. It goes into detail at length about the various designs and what each of them meant....It has an absolute TON of information and exactly what each part of the HUD is and does. This will probably be VERY worthwhile for you to read and look at if you want to continue doing it and make it as realistic as possible.


Yeah, I don't really 'geek out' much. I'm an electrical engineer, 99% of my time is spent geeking out in some way.
 
If you use a buffer, for instance an AND gate that has both inputs (A and B) tied to the output of the Trinket, and put 4 of them together (a QUAD AND gate part, with all the inputs tied together, and all the outputs tied together) you should easily be able to drive any logic level MOSFET out there. The real issue is putting enough current into the gate of the FET to cause it to change state. The more capacitance the gate has, the more current needed to switch it quickly. It's just one way of dealing with the issue.

Other than that, everything looks good. I'm kinda surprised that you used a single large LED for the center, instead of just a single NEOPIXEL. You could then have them all change colors. (That's just what I did, and was just wondering)

The HUD isn't looking bad. The biggest issue I would see is making the altitude and everything show up properly.

Have you seen this?
Jayse Hansen Portfolio | Iron Man's Mark VII HUD | Jayse Hansen Portfolio |

This is the gentleman that designed the HUD for Iron Man in Avengers. It goes into detail at length about the various designs and what each of them meant....It has an absolute TON of information and exactly what each part of the HUD is and does. This will probably be VERY worthwhile for you to read and look at if you want to continue doing it and make it as realistic as possible.


Yeah, I don't really 'geek out' much. I'm an electrical engineer, 99% of my time is spent geeking out in some way.

Thanks for the advice. I'll fool around with it this weekend and see if I can improve on the repulsor circuit setup.

Ha! I was just on that site again this morning! I swear I have almost every image of those HUD designs saved somewhere in my Evernote research archives. The Iron Man HUD is fantastic, and I do love some of the design choices. However, since I'm doing all of this in Processing and any sort of animation has to be done by numbers in coordinate space, I'm keeping the first version of this simple for now. I also want everything on my HUD to be actual, relevant data to the wearer/cosplayer, The IM HUDs are beautiful works of art, but a bit cluttered and busy if you actually went to use them. So for now, I'm building a fairly boring, utilitarian HUD loosely based off some of the ideas from the Mark II HUD. If I ever can afford a copy of NUKE or NUKE training, then maybe I'll get a true interface going.. I could probably even pre-render some of it in Blender and use .GIF files everywhere. But that's later. One thing I would like to keep intact is the idea of "skins", so that other folks can come along later and make their own backgrounds, horizons, crosshairs, etc. at the specific pixel size and just drop them into the Data folder.

Oh, and the text on the top left-hand corner is for debug purposes; I'll remove it at some point once I'm sure all my graphs are correct. I can probably make it smaller for now, though.

Cheers, and thanks again for all your help so far!
~Lexikitty
 
Wow!!! This is just... WOW!!! :thumbsup

Aw, thanks very much! :D I'm glad folks like what they see!

A tiny update on the HUD, of a mostly boring technical flavor. I've managed to get the bottom half of the HUD done in 3D, so Processing is drawing a separate coordinate matrix for each individual panel. The yellow rectangles represent the borders of each 3D plane, where data can go. This also means they can fold/unfold in future startup/mode switch animations. I've also rigged the repulsor bar graphs to map to a 0-100 value, so I can animate that in the future too. Populating all of this will take a while, as it's all done by numerical coordinates - only the blue lines are pre-drawn. Let me know what you think!

HUD3D Only.png

Oh, and I've disabled the camera/sensors for a bit just for faster graphical debugging.

I keep having a mental war as to how close I want to get to the Iron Man HUD down the line, or whether I'm going to just walk away from it entirely and build something all my own. Moral crises....*sigh*.

Cheers,
~Lexikitty
 
Looks great!

Personally, being the purist that I am, I'd go for something as close to one of the more basic HUD's as possible and then move on from there.

Either way, it looks great.

I have one slight question......only because it interests me. Do you think you'll build in the ability to take pictures and video using the camera?
 
Looks great!

Personally, being the purist that I am, I'd go for something as close to one of the more basic HUD's as possible and then move on from there.

Either way, it looks great.

I have one slight question......only because it interests me. Do you think you'll build in the ability to take pictures and video using the camera?


Thanks! Yea, I kind of feel that way too. Maybe once I've got the prototype working I'll tear it down and do a proper lightweight version of the Mk 7 or 42 HUDs. I wonder if there are any reference photos of the Mk 40/Shotgun or Mk 16/Nightclub HUD's around here...

Swiping stills from the video feed is pretty easy in Processing, or so I've read from the use of the Video library. I haven't actually tried it, but I will sometime this week just for funsies. In the original grandiose version of this project that I had in my head, the Pi could serve a video feed through a hotspot to my website, where people could go and see semi-live footage from inside the suit. And that's still on the todo list, but wayyyy down at the bottom somewhere. :) Why do you ask?

~LK
 
Thanks! Yea, I kind of feel that way too. Maybe once I've got the prototype working I'll tear it down and do a proper lightweight version of the Mk 7 or 42 HUDs. I wonder if there are any reference photos of the Mk 40/Shotgun or Mk 16/Nightclub HUD's around here...

Swiping stills from the video feed is pretty easy in Processing, or so I've read from the use of the Video library. I haven't actually tried it, but I will sometime this week just for funsies. In the original grandiose version of this project that I had in my head, the Pi could serve a video feed through a hotspot to my website, where people could go and see semi-live footage from inside the suit. And that's still on the todo list, but wayyyy down at the bottom somewhere. :) Why do you ask?

~LK

I only ask because for a convention, being able to take photos without getting a 'real camera' out is awesome. That was half the reason I enjoyed the Adafruit coding for the camera, because it allows me to take pictures (and video with the version I have). That's all. Allowing it to have a bit of functionality as well as utility is a good thing IMHO. ;)
 
I only ask because for a convention, being able to take photos without getting a 'real camera' out is awesome. That was half the reason I enjoyed the Adafruit coding for the camera, because it allows me to take pictures (and video with the version I have). That's all. Allowing it to have a bit of functionality as well as utility is a good thing IMHO. ;)

Oh, that's a fantastic idea! I really like that. Provided you're using a decent enough webcam for the HUD, that could definitely be plenty viable. The RPi camera would be better, but....the framebuffer trick for overlay means you'd lose your visual feed for a few seconds while raspicam shut down, fired up, took a picture, shut back down, and came back as the overlay. And hey, you could hide a flash in the chest panel that'd double as a uni-beam blast. :D

~LK
 
Oh, that's a fantastic idea! I really like that. Provided you're using a decent enough webcam for the HUD, that could definitely be plenty viable. The RPi camera would be better, but....the framebuffer trick for overlay means you'd lose your visual feed for a few seconds while raspicam shut down, fired up, took a picture, shut back down, and came back as the overlay. And hey, you could hide a flash in the chest panel that'd double as a uni-beam blast. :D

~LK

I don't know about you, but using the Raspberry Pi cam is what I'm pretty much planning on doing.
I considered doing this NOIR camera as well, and adding in some IR LED's into both the chest and the hands, just to provide myself the ability to then illuminate things in the dark and still see.....

But I don't know about you, but not being able to 'see' for a few seconds while it takes the picture is the least of my concerns. Just having the ability to do it makes it worthwhile IMHO.

As far as using the chest or repulsar's as a flash, that'd be a great idea as well. If you can get the timing down.
 
I don't know about you, but using the Raspberry Pi cam is what I'm pretty much planning on doing.
I considered doing this NOIR camera as well, and adding in some IR LED's into both the chest and the hands, just to provide myself the ability to then illuminate things in the dark and still see.....

But I don't know about you, but not being able to 'see' for a few seconds while it takes the picture is the least of my concerns. Just having the ability to do it makes it worthwhile IMHO.

As far as using the chest or repulsar's as a flash, that'd be a great idea as well. If you can get the timing down.

I haven't tossed the RPi camera aside totally yet, but it's been somewhat sidelined by the Processing + USB webcam setup. Once I get Mk 0.5 working, I'll see what happens when I drop it on a Pi, and see how much sanity it would cost to port it. I thought about using the NOIR camera too, but since the interface only supports one camera board, I just went with the regular. I guess I could use netcat to stream the NOIR board's feed to the main RPi and switch on-the-fly, but...maybe later.

And yea, if you didn't mind the visual blip, you could use raspicam to take the picture from within your Python script. You'd just need to kill the HUD feed first, which would be easy enough if that was in a separate batch script. That could also easily handle the pins for the flash.

~LK
 
Neeeeeeeeeeeeeeeeeeeeerd.


No but in all seriousness. THIS IS AWESOME.
I've seen all these suit replicas that can move the helmet up and down, and that's great. But a near-fully functioning suit? Holy crap!
Just uh... make sure the missiles aren't armed unless you're going to use em eh?
Also, how advanced are you planning on making this? And wouldn't the system make the hands/back/helmet bulkier?

- - - Updated - - -

Oh and, I didn't read the entire thread and don't know if this was mentioned, but what about seeing out of the helmet? Would it be better to just
have one screen in the helmet, and have a camera, or cameras to see out? The only issue here I could see is if the camera was damaged.
I'm also pretty sure this is what Tony did because flying around faster than the speed of sound can make it hard to see.
 
Neeeeeeeeeeeeeeeeeeeeerd.


No but in all seriousness. THIS IS AWESOME.
I've seen all these suit replicas that can move the helmet up and down, and that's great. But a near-fully functioning suit? Holy crap!
Just uh... make sure the missiles aren't armed unless you're going to use em eh?
Also, how advanced are you planning on making this? And wouldn't the system make the hands/back/helmet bulkier?

- - - Updated - - -

Oh and, I didn't read the entire thread and don't know if this was mentioned, but what about seeing out of the helmet? Would it be better to just
have one screen in the helmet, and have a camera, or cameras to see out? The only issue here I could see is if the camera was damaged.
I'm also pretty sure this is what Tony did because flying around faster than the speed of sound can make it hard to see.

Aw thanks! :) Glad you like it! Dang right I'm a nerd, and proud of it. ;)

It was mentioned above, but the system uses a camera wired to a computer, and a set of two screens (an HMD) inside the helmet. The helmet will be slightly bulkier (mainly, just set farther away from the face), and all of the computer systems will be underneath the flaps/back thruster panel, so it shouldn't be that noticeable. The missiles will be Nerf-tipped (for now), so they shouldn't pose any threat except to my girlfriend's sanity.

As far as functionality, I'd like (or will die trying) to make this replicate as many of the features of the actual suit(s). HUD provides data from suit joins, servo positions, temperature, rotation, internal forces, panel integrity, etc. (Funnily enough, this part has been fairly painless). Repulsor blasts controlled by arm movements, moving flaps and armor panels, power-assisted arm and leg assemblies, voice control, and so on. While I'm pretty sure my chosen chassis will be Nightclub-based, I might stray a bit from canon and add an arm missile or wrist laser, because why not. The idea behind it all would be this - if tomorrow, somebody handed me the real tech for repulsors, uni-beams, and flight stabilizers straight from Tony's shop, I would already have the suit, computer systems, and software to use them. With a teensy bit of reinforcement on the "suit" part of that, since I doubt 3D printed plastic, foam, and sheet metal would do all that well at supersonic airspeeds.

That's the dream, anyway. :)

~LK
 
Annnnnd one last update before the work week starts again. Finished the coordinate spaces for all of the bottom panels and gave the repulsor bars some color. Now, as they "recharge", they'll turn colors - red for <30%, yellow for 30-65%, and blue for >65%. I might add a gradient to the background to simulate curved glass, just since it actually gets fairly hard to read in bright light.

HUDv0_4a.png

Now that (half) of the complicated mathy bit is done, I'm going to work a bit more on the design of the suit, particularly how this head camera and IMU sensor will be mounted (and polishing up the aesthetics of it, for fun :) ).

~LK
 
Ha, my girlfriend just told me about this.

RAD.

Thanks! :D

Just a few updates (I was away on vacation for a bit, but now I'm back into the swing of things):

In the process of tinkering, I thought I might make a stab at maybe changing the interface to the Mark VII HUD, just to see how difficult it would be. This is as far as I got before I realized how bad of an idea that would be within Processing.

3D Icons Fail.png

If I wanted to be accurate, I'd have to wrap dynamic text along the paths as well as drawing bar graphs vertex-by-vertex, so to keep any sanity I might have accidentally left lying around, I ditched it. Also the various panes move and scale around a common origin when switching between modes - something else Processing isn't entirely great at. Python, maybe, but I'm in too deep now to completely switch.

Also in the last few weeks, I've upgraded the camera from a Microsoft Cinema to a Logitech C615, which has a slightly better lens and decent autofocus, not to mention 1080p video if I ever really wanted it. I've 3D printed the skeleton of the forehead bracket, and taped a temporary mounting platform out of foamboard to it.

P1110065.JPG

The idea will be to make an internal endoskeleton with tall supports that will hold the (fiberglass, probably) exoskeleton pieces on top. That way there's some room in there to stuff sensors, motors, and whatnot. It might look a tad big (I'm already kind of tall at ~5"11" :/ ) but that's reality, I guess.

I've also populated the HUD with more widgets, including a clock, system uptime, heading for the helmet in degrees and compass direction (N shows up red), communication with the sensor boards (more on the way), and information on what camera settings are being used. I've also added a sort of glass-ish gradient behind the widget panels to make things more readable - I was having a lot of trouble seeing anything in lighter environments. I'll probably also need to change the horizon and crosshair colors too. Shown here with a light and dark background, and a close object to test focal length.

Updated Background+Camera.png

I think that's everything. As always, please let me know if you have any suggestions/comments!

Cheers,
~LK
 
This thread is more than 8 years old.

Your message may be considered spam for the following reasons:

  1. This thread hasn't been active in some time. A new post in this thread might not contribute constructively to this discussion after so long.
If you wish to reply despite these issues, check the box below before replying.
Be aware that malicious compliance may result in more severe penalties.
Back
Top