Hey, you should login or register!

Welcome to MNFurs, a local community site where fans of anthropomorphic animals and artists can gather to meet each other locally in the Twin Cities and surrounding area; forming friendships, meeting new people, educate others, and help out the local community. To access chat, forums, and the additional features of this site you must register for a free account or log in.

New Suit Project "Shama La Leon" (construction journal) (final attempt to post)

Home Forums General Discussions Fursuiting New Suit Project "Shama La Leon" (construction journal) (final attempt to post)

Viewing 15 posts - 16 through 30 (of 30 total)
  • Author
    Posts
  • #49540 Quote
    Ah, was just wondering because your segments have two axes. Hm…maybe having the anchor for the cable further up on the tail and having the tip section on some kind of spring with just enough tension to return it to center when the tail is moved so it lags a little behind . Actually, come to think of it, relocating the horizontal motion motors lower on the tail would give it more of a cat like motion… but anyway. Cool ^_^
    #49541 Quote
    The thought had occurred to me in the past, or to have the cable not extend the full length of the tail.  But this is what I achieved with just a rope and alternating layers of hard and soft foam:

    I’m essentially replicating that in plastic with joints, I just intend to let inertia do the work of animating it =3

    • This reply was modified 6 years, 6 months ago by Shoku.

    "The problem is not that there are too many idiots in the world, the problem is the distribution of lightning."
    - Mark Twain

    #49547 Quote
    ^_^
    #49550 Quote
    It looks really good! I just made a tail all hand sewed. I made a belt loop and the loop came out this weekend at the picnic :/. I’ll have to resew and glue it again.

    Music makes the world go around!

    #49552 Quote
    That looks very nice. I like the pivoting action.

    *Howls in approval*

     

     

    Engineer by day, artist by night.

    #49576 Quote
    Today In History!

    I finished assembling the tail-housed power burrito.  And then I sat staring at it for quite a while.
    https://photos.app.goo.gl/PkAH43NPnXVuwSvF3
    https://photos.app.goo.gl/zbRmOLGzGukKzE8C3

    Did I really trust my wiring?  I have 20 x 4 amps of SBECs connecting to 120 amps worth of battery all contained in, as the name suggests, a package the size of a burrito.  #thingsIshouldbewearingashirtfor

    I worked up the courage to plug it in and *drumroll* nothing exploded!  I did something right!  I MEAN EVERYTHING ALWAYS WORKS ALL THE TIME THATS NOT A BURN MARK!

    Other updates include a longer tail section to show off:
    https://photos.app.goo.gl/vt6dhd5mwYhJ3DHG3

    And the best yet:  I have the FurPainter test code running (after a lot of expletives, had to resort to other languages) on the Teensy!

    This demonstrates that I can access the embedded SD card (and make the existing code actually read it, that was….. fun), I can write to the pixels using the OctoWS2811 library, and I can drive the NeoPixels without the use of a logic level shifter.  Everything is falling into place!  I have also confirmed today that none of the pins I’m using overlap (OctoWS2811 8 outputs are on 8 fixed pins, SPI is on 4 fixed pins, and I2C is on 2 fixed pins, and I still have plenty of PWM-capable outputs left over).

    Note the “redout” condition at the end.  I believe I have determined this is due to low supply voltage but I haven’t been able to explain why, or even reproduce the effect yet.  It may have been thermal throttling on the SBEC:  I didn’t have a fan installed during that test.

    Next task is to finish designing the mount plate with the initial hinge sections and to continue printing spine sections.  I actually have more than are visible here; I ran out of super glue to attach the 2 halves together.

    "The problem is not that there are too many idiots in the world, the problem is the distribution of lightning."
    - Mark Twain

    #49585 Quote
    for (int j = 3; j >= 0; j--) { // 3 to 0 to calculate bit position value
    for (int k = 0; k < 3; k++) { // 0 to 2 to calculate color value
    int pos = i * 24 + 3 - j + k * 8 + 4;
    packetData[pos] = (byte)((data[k] >> 4) & (1 << j) >> j);
    packetData[pos + 4] = (byte)(data[k] & (1 << j) >> j);
    //print("pos:",pos," ");
    //println((byte)((data[k] >> 4) & (1 << j) >> j));
    //System.out.format("pos: %s",pos);
    }
    }

    I would just like to point out this is the code I spent all of yesterday and most of today writing and I want to jump off a cliff now, but if it works I’ll put on a parachute first.

    "The problem is not that there are too many idiots in the world, the problem is the distribution of lightning."
    - Mark Twain

    #49589 Quote
    Today’s update is about data.

    The nice thing about the library I’m using to drive the lights is you can read data directly from the SD card onto the drawing buffer.  My old code in effect worked like this:

    if (pixel data block)
    for (x = 0 to 139)
    read Red from SD
    read Green from SD
    red Blue from SD
    setPixel(x, Red, Green, Blue)
    next
    endif

    And this worked, but it is extremely slow.  I was reading 1 byte at a time from the SD card.  Ideally, and what OctoWS2811 allows me to do, I want to read the entire frame into memory at one time.  A, this is much faster.  B, this doesn’t require processing logic to turn RGB values into the data the strip requires.

    What this requires, however, is a way to convert the pixel data into the Teensy-readable format when the video is encoded.  The old system simply record RGB hex triplets, one for each pixel for each frame.  The new system is a bit different.

    0b1111 1111 is binary for the value 255.  It can be written as hexadecimal as 0xFF.  This is important because the way data is read for the NeoPixels looks like this:

    0x01010101 0x01010101 0x00000000 0x00000000 0x00000000 0x00000000

    Notice the similarity to binary?  This is the pixel hex code for the color green on channel 0 pixel 0 (neopixels are in the GRB order instead of RGB).  But gets even more complicated.  If we wanted to use the color #000100 (00 red 01 green 00 blue) the NeoPixel hex would look like this:

    0x00000000 0x01000000 0x00000000 0x00000000 0x00000000 0x00000000

    The read order is reversed so the binary 0b0000 0001 is translated to 0x00000000 0x01000000.

    This is further complicated by the addition of the other channels.  What I have shown is the 6 integers that control all 8 strips.  Additional strip values are added to each other (channel 0 is 1’s, channel 1 is 2’s, channel 2 is 4’s etc…) so if the same bit is on across all strips the value is FF instead of 01.

    The code I posted the other day was my attempt to convert the data.  Which didn’t work.  Instead I pulled the code from a different program and persuaded it to work (with a hammer) with the code I’m using.  The end result is this:

    for (int i = 0; i < numPixels; i++) {
    int pixelLocation = pixelLocations[i];
    int pixel = pixels[pixelLocation];

    int red = (pixel & 0xFF0000) » 16;
    int green = (pixel & 0x00FF00) » 8;
    int blue = (pixel & 0x0000FF);
    red = gammatable[red];
    green = gammatable[green];
    blue = gammatable[blue];
    int tpixel = (green « 16) | (red « 8) | (blue);

    int mask;

    for (mask = 0x800000; mask != 0; mask »= 1) {
    byte b = 0;
    if ((tpixel & mask) != 0) b |= 1;
    packetData[offset++] = b;
    }
    }

    The result of which, while it looks the same, is code that runs much faster and can handle many, many times the LEDs.

    That video had to be slowed down to match the audio, but the framerate is consistent so that’s simply a matter of adjusting the timing value (the old value was for the old, slow code on a slower processor).

    "The problem is not that there are too many idiots in the world, the problem is the distribution of lightning."
    - Mark Twain

    #49636 Quote
    Well I feel sick from breathing solder fumes all night, and I glued my fingers together more than once, but WORTH IT!

    The lion’s share of the tail structure is complete.

    https://photos.app.goo.gl/kPDk1VSUip5hedFj1 (you can see the S-pattern wires I’m using to allow movement between joints)
    https://photos.app.goo.gl/adJE6C7NPGjRIG9f1 (my cheaty, cheeky way of illuminating the tip without printing more structure)
    https://photos.app.goo.gl/zF5archMgJmG0OUD3 (sooooo preeeeeetyyyyyyyyy)
    https://photos.app.goo.gl/XRmO4zH3tS37sd7d2 (technically one of my legs, but makes a good tail fur test)

    I have to let glue dry on a few joints that misbehaved and then tomorrow I hope to finish the mounting plate and I can get to waggin!

    "The problem is not that there are too many idiots in the world, the problem is the distribution of lightning."
    - Mark Twain

    #50763 Quote
    Well been a long time since an update but here it goes.

    The first test of the tail was largely successful.  It ran for the entire 2018 holiday party (and then some) without any major issues.  However when I later presented the tail on Adafruit Show And Tell I found the spine had broken without me realizing it.  I wasn’t overly hard on the tail so this may facilitate a redesign of the hinge mechanism.  I haven’t decided yet (my presentation starts at 17:47).

    Moving onto the head.  I had originally intended the design to use the Raspberry Pi Zero W (because that’s the one I had) for the eye animations.  However this is what the framerate looked like.

    The instructions for setting up the code recommended using a Pi 3 to download and install the code and transfer the SD card to a Pi Zero, so after putting the card back in the Pi 3 I got this:

    Colossal improvement in framerate.  The size difference isn’t as bad as I expected it to be, once I remove some of the headers from the board.  I think I’m going to adapt the design to use the Pi 3 instead.

    Finally I did some tweaking of the default vectors and graphics to produce a more wolf-like look for the eye.  Bear in mind my phone’s camera really desaturated the color.

    https://photos.app.goo.gl/D92nOU8K5LEOifxR2

    Following that I did a very rough test fitting in the head.

    https://photos.app.goo.gl/eXGwWPkCgZd91Hv62
    https://photos.app.goo.gl/tSooXYUEROHvwRDl1

    The displays aren’t a perfect fit and have to be angled very slightly, but the tilt isn’t really noticeable.  I believe my next step is going to be test-printing some 3D holders for the assemblies so I can start fitting the camera in with the displays as well.

    • This reply was modified 6 years, 2 months ago by Shoku.

    "The problem is not that there are too many idiots in the world, the problem is the distribution of lightning."
    - Mark Twain

    #50832 Quote
    Small update for today, I’ve begun working towards the final glove circuit.  I’ve moved the chirp detection to the smaller Teensy 3.2, heavily trimmed down the code, and started building the circuitry for the hall effect (magnetic) switches.

    This video is the full length of the song to test the timing and make sure the Teensy stays accurate, although the glove won’t be handling the timing in the final build; it will simply be telling the tail processor when to start the light animation (which will tell the HUD, which will show me an indicator so I can start my performance on beat).

    In the next update I hope to have more of the glove circuit prototyped; the vibrate feedback, the magnetic sensor buttons, and the wireless communication.  The idea is to have the glove send a command and be able to receive confirmation, which it will relay discretely to me via the vibrate motor (from an old LG phone) in the wrist band of the inner glove.

    "The problem is not that there are too many idiots in the world, the problem is the distribution of lightning."
    - Mark Twain

    #50881 Quote
    Short and salty today.  A major setback has happened.

    While I have been posting most of the code I write to github, I had apparently forgotten to upload the version of the code that ran on the Teensy using the embedded SD card.  It is, in theory, possible that I saved it to the D drive but since Arduino sketches are so small I usually don’t bother changing the directory (which defaults to My Documents).

    There is a strong chance I lost hours and hours worth of work.  Let my misfortune serve as a reminder:  Backup early, backup often.

    "The problem is not that there are too many idiots in the world, the problem is the distribution of lightning."
    - Mark Twain

    #50912 Quote
    I’m just curious, is anyone interested in my progress updates?  I don’t get many replies and I get hardly any video views.

    "The problem is not that there are too many idiots in the world, the problem is the distribution of lightning."
    - Mark Twain

    #50928 Quote
    I’m enjoying reading along and seeing the progress. I know nothing of coding and such, so it’s fun to see just how much work goes into something most people assume is simple when it’s finished and working.
    #51274 Quote
    Well as there doesn’t seem to be much interest here I’m going to discontinue the journal.  I am continuing to post build videos on my YouTube.  If you’d like to keep following along you should follow me there.  http://www.youtube.com/snowsongwolf

    I am also making my build videos public now instead of unlisted (WolfTEC Projects).  Also doing a proper editing job on them.  Enjoy!

    "The problem is not that there are too many idiots in the world, the problem is the distribution of lightning."
    - Mark Twain

Viewing 15 posts - 16 through 30 (of 30 total)
  • You must be logged in to reply to this topic.
 
 

People Who Like Thisx

Loading...

People Who viewed ThisX

The RSVP Plus One is for one-time guests or guardians of the MNFurs member going to event.

If the Plus One is for an MNFurs member, they need to RSVP themselves.