fiduciary

Author Topic: TeensySaber Software Discussion  (Read 67085 times)

0 Members and 2 Guests are viewing this topic.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: TeensySaber Software Discussion
« Reply #135 on: November 28, 2017, 12:16:21 PM »
Haven't tinkered with slashes yet, but I just changed both Mono/Poly speed lines to:
Code: [Select]
if (speed > SWING_THRESHOLD) {
and popped this line in my config:
Code: [Select]
#define SWING_THRESHOLD 200.0 //default 250.0
It's definitely a nice improvement. I'll keep playing with the values until I'm happy

Also, updated my power-saving calculator with standard RGB values. Designed to make the brightest color possible while keeping power consumption down to ~2.5A per strip. Useful for me so I'm not constantly swapping batteries at conventions:

Low-Power Color Selector

I've had good experience using this cool white as a FoC color against a Red <255, 0, 0> main, but it should also work well for a Silver main blade:
Code: [Select]
Rgb<65, 95, 95>


I'll make sure to include the SWING_THRESHOLD in the config file for next version. :)

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: TeensySaber Software Discussion
« Reply #136 on: November 28, 2017, 12:17:45 PM »
BTW, the color of the clash should have very little impact on the battery life, since clashes are so short-lived.

Offline KanyonKris

  • Padawan Learner
  • **
  • Posts: 72
  • Um...Hello?
Bluetooth
« Reply #137 on: November 29, 2017, 04:48:37 AM »
Bluetooth is way cool.

Since it's inside a metal enclosure, how is the range?

I know this isn't included in the current firmware, but is it technically feasible to upload new firmware and sound fonts over Bluetooth?  It would be very nice to never need to open up the saber.

Offline Kouri

  • No Force
  • *
  • Posts: 39
  • ~
Re: TeensySaber Software Discussion
« Reply #138 on: November 29, 2017, 05:50:52 AM »
It's not really so much about the clash as preventing mixed colors from pulling 2-3x as much power as single colors. Up to the end user to balance brightness and power draw. Also helps prevent bright white flashes from causing a significant voltage drop on weaker cells that might shut off the board.

That said, I've got a high-drain cell in my crossguard, and haven't yet had any issues with the default  WHITE and YELLOW values on TeensySaber.

As for bluetooth range, I can't speak for this setup, but the last time I toyed with a bluetooth module, I had really poor reception in the aluminum hilt. I got around that by drilling some holes near the switch, running some black wire through the holes to the outside of the hilt, and soldering those wires to the antenna traces on the module. I forget exact values, but I want to say it increased range from about 2-3ft to 20ft.



Also, I originally misunderstood Drag as a feature that would activate if the lockup sounds were renamed/replaced with the appropriately named file. After looking at the code, I realized it's basically a special lockup that only triggers when the blade is pointed toward the floor.

It's a super nifty effect, but there really ought to be some warning in the build guide that TeensySaber expects to be installed with the SD card facing the pommel. I very nearly installed it the other way around for cleaner wiring.

It's taking me a bit to wrap my head around all the code since I've never really worked with anything more complex than PHP and Basic, but I find myself building up a large to-do list of tweaks to the code, so at least this is a fun way to learn C.

EDIT: So I'm taking a break from the more complicated code to play around with blade styles. I don't see EasyBlade documented on the software page, but looking at the code, I'm led to believe it's basically SimpleClash with audioflicker incorporated in the clash effects?

EDIT2: Took the advice for slash code. Polyphonic swings looking like:
Code: [Select]
if (speed > SWING_THRESHOLD) {
      if (!swinging_ && state_ != STATE_OFF) {
        swinging_ = true;
        if (speed - average_speed > SLASH_DELTA){
          Play(&slsh);
        } else {
          Play(&swng);
        }
      }
    } else {
      swinging_ = false;
    }

So far I'm happy with CLASH_THRESHOLD_G at 3.0 and SWING_THRESHOLD at 150. Still need to dial in SLASH_DELTA. 15 and 20 were both too low.
« Last Edit: November 29, 2017, 08:58:01 AM by Kouri »

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: Bluetooth
« Reply #139 on: November 29, 2017, 10:33:22 AM »
Bluetooth is way cool.

Since it's inside a metal enclosure, how is the range?

I know this isn't included in the current firmware, but is it technically feasible to upload new firmware and sound fonts over Bluetooth?  It would be very nice to never need to open up the saber.

I don't actually know what the range is yet, as my bluetooth chip isn't in a hilt yet.
I would expect the hilt to work as a faraday cage, so unless an antenna is placed on the outside, it might not work at all.
BLE is rated for 60 meters under ideal conditions, obviously placing the antenna inside a metal container is not ideal conditions. :)

It is technically feasible to upload new fonts and firmware over bluetooth, but I'm not sure you would want to as BLE is pretty slow.
I would love to integrate the app with soundfont.com though so that fonts could be bought and uploaded from your phone or computer directly.

Firmware updates are a little trickier, but could be accomplished with a two-step process:
  1) upload firmware to sd card
  2) firmware is flashed from sd card

I'm probably going to work on moving some configuration items out of the source code and into config files in the future so that they can be
dynamically changed without having to upload new firmware. I want to keep the config files fairly simple though, so I don't expect the need to upload
new firmware to away completely.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: TeensySaber Software Discussion
« Reply #140 on: November 29, 2017, 10:42:47 AM »
It's not really so much about the clash as preventing mixed colors from pulling 2-3x as much power as single colors. Up to the end user to balance brightness and power draw. Also helps prevent bright white flashes from causing a significant voltage drop on weaker cells that might shut off the board.

That said, I've got a high-drain cell in my crossguard, and haven't yet had any issues with the default  WHITE and YELLOW values on TeensySaber.

As for bluetooth range, I can't speak for this setup, but the last time I toyed with a bluetooth module, I had really poor reception in the aluminum hilt. I got around that by drilling some holes near the switch, running some black wire through the holes to the outside of the hilt, and soldering those wires to the antenna traces on the module. I forget exact values, but I want to say it increased range from about 2-3ft to 20ft.




Good to know

Quote
Also, I originally misunderstood Drag as a feature that would activate if the lockup sounds were renamed/replaced with the appropriately named file. After looking at the code, I realized it's basically a special lockup that only triggers when the blade is pointed toward the floor.

It's a super nifty effect, but there really ought to be some warning in the build guide that TeensySaber expects to be installed with the SD card facing the pommel. I very nearly installed it the other way around for cleaner wiring.

Good point, I should add that somewhere.
Although, it's pretty simple to insert a - somewhere to negate the right axis in the acceleration detection code.

Quote

It's taking me a bit to wrap my head around all the code since I've never really worked with anything more complex than PHP and Basic, but I find myself building up a large to-do list of tweaks to the code, so at least this is a fun way to learn C.


Feel free to share the todo list so that other people (including me) can work on it as well. :)
Also, please consider sharing any changes you make so I can include them in the next release of the code.
Btw, it's C++, not C, and it's written a little weird because I try to avoid using malloc() when I write code for small processors.
And I really should split the file up 10000 lines of code in one file can be hard to work with.

Quote
EDIT: So I'm taking a break from the more complicated code to play around with blade styles. I don't see EasyBlade documented on the software page, but looking at the code, I'm led to believe it's basically SimpleClash with audioflicker incorporated in the clash effects?

Missed the Lockup and Blast effects.
Basically it just adds clash, lockup and blast effects to whatever colors you select.
I will add it to the documentation.

Quote
EDIT2: Took the advice for slash code. Polyphonic swings looking like:
Code: [Select]
if (speed > SWING_THRESHOLD) {
      if (!swinging_ && state_ != STATE_OFF) {
        swinging_ = true;
        if (speed - average_speed > SLASH_DELTA){
          Play(&slsh);
        } else {
          Play(&swng);
        }
      }
    } else {
      swinging_ = false;
    }

So far I'm happy with CLASH_THRESHOLD_G at 3.0 and SWING_THRESHOLD at 150. Still need to dial in SLASH_DELTA. 15 and 20 were both too low.

I'm not actually sure that this is the right way to detect slash vs. swing, I just suggested it because i seemed better than
first triggering a swing and then a slash. Let me know how it works out.

Offline Kouri

  • No Force
  • *
  • Posts: 39
  • ~
Re: TeensySaber Software Discussion
« Reply #141 on: November 29, 2017, 11:45:12 AM »
Well my first idea of adding a nested speed check didn't trigger any slashes (I'm using Naigon's "Testing Testing" font to verify). The only other idea I can think up is checking for a slash speed before checking for a swing speed, but it's probably a waste of CPU to compare speed twice every step. At least your way only checks for slash speeds after meeting the minimum swing speed.

Code: [Select]
if (speed > SLASH_THRESHOLD) {
      if (!swinging_ && state_ != STATE_OFF) {
        swinging_ = true;
        Play(&slsh);
        }
      }
    } else if (speed > SWING_THRESHOLD) {
      if (!swinging_ && state_ != STATE_OFF) {
        swinging_ = true;
        Play(&swng);
        }
      }
    } else {
      swinging_ = false;
    }

As for my to-do list, in no particular order:
  • Split parts of "lightsaber.ino" into separate "input.h", "motion.h", and "lighting.h" modules
  • Read config variables from a "config.ini" file on SD root.
  • Incorporate delayed ignition to other blade styles
  • Add missing blaster-block effects to flame blade (thinking I can just make the clash animation play), and maybe override the last few pixels to enable the drag effect.
  • Write a variant flame blade style that extinguishes tip-to-base like a standard saber blade
  • Add a third color parameter to flame blade that defines the dark pulses - hoping to make the style a little brighter Nevermind,
     I just needed to bump up the A parameter on FIRE1_NORMAL
  • Tweak Drag effect so that it only effects the first blade
  • Alternate single-button mode (press ignite, press blaster-block, hold+clash lockup, hold+release or extended-hold to retract)

Most of it's saberstaff and crossguard optimization that won't effect 98% of end-users, so it just made sense to tackle on my own and share my findings afterward.

And I wasn't sure about the math needed for the drag-detection code. If it really is just a negative, I was thinking of adding an ORIENTATION variable to the config that could be set to 1 or -1 depending on which way the board's facing, then just multiply that in the drag check.

Finally, your bluetooth announcement has me thinking about replicating Prizm's multi-blade support (All neopixel blades in series, Pixels 1-20 designated as crossguards, pixels 21-160 designated as main blade, for example) so that I could free up those two data pins for bluetooth or Zigbee modules, but that's *really* low on my priorities.

EDIT: Looks like a Slash Delta of ~30 works great. Motion tracking on this board feels a LOT better now.
« Last Edit: November 29, 2017, 04:59:59 PM by Kouri »

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: TeensySaber Software Discussion
« Reply #142 on: November 29, 2017, 03:54:45 PM »
And I wasn't sure about the math needed for the drag-detection code. If it really is just a negative, I was thinking of adding an ORIENTATION variable to the config that could be set to 1 or -1 depending on which way the board's facing, then just multiply that in the drag check.

I think it would be better to do the multiplication in the motion sensor code, otherwise it may need to be done in multiple places.
(Like the POV blade for instance.)


Offline Kouri

  • No Force
  • *
  • Posts: 39
  • ~
Re: TeensySaber Software Discussion
« Reply #143 on: November 30, 2017, 07:38:07 AM »
I'm trying to adjust Flame Blade to at least show the clash effect on a blaster block.

Current code is:

Code: [Select]
      FireConfig config(0,0,0);
      if (blade->clash()) {
         config = clash_;
      } else if (On(blade)) {
        if (SaberBase::Lockup() == SaberBase::LOCKUP_NONE) {
          config = normal_;
        } else {
          config = lockup_;
        }
      } else {
         config = normal_;
         config.intensity_base = 0;
         config.intensity_rand = 0;
      }

And I'm thinking of tweaking it to:

Code: [Select]
      FireConfig config(0,0,0);
      if (blade->clash()) {
         config = clash_;
      } else if (On(blade)) {
        if (SaberBase::NumBlasts > 0) {
          config = clash_;
        } else if (SaberBase::Lockup() == SaberBase::LOCKUP_NONE) {
          config = normal_;
        } else {
          config = lockup_;
        }
      } else {
         config = normal_;
         config.intensity_base = 0;
         config.intensity_rand = 0;
      }

I'm just not sure that "if (SaberBase::NumBlasts > 0)" is the best way to identify when a blast should be triggered.

Also wanting to change the retraction so it's like a normal saber blade. My current understanding is Fire Blade basically plays an animation of random colors travelling up the blade, and on retraction, the animation stops adding new colors and lets the existing ones finish travelling. What I'd like to do instead is, when retraction is triggered, start lowering the num_leds variable (or some temporary copy of it) while maintaining the animation, so the fire just travels a shorter distance each iteration until it stops emitting entirely.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: TeensySaber Software Discussion
« Reply #144 on: November 30, 2017, 02:25:17 PM »
I'm trying to adjust Flame Blade to at least show the clash effect on a blaster block.

Current code is:

Code: [Select]
      FireConfig config(0,0,0);
      if (blade->clash()) {
         config = clash_;
      } else if (On(blade)) {
        if (SaberBase::Lockup() == SaberBase::LOCKUP_NONE) {
          config = normal_;
        } else {
          config = lockup_;
        }
      } else {
         config = normal_;
         config.intensity_base = 0;
         config.intensity_rand = 0;
      }

And I'm thinking of tweaking it to:

Code: [Select]
      FireConfig config(0,0,0);
      if (blade->clash()) {
         config = clash_;
      } else if (On(blade)) {
        if (SaberBase::NumBlasts > 0) {
          config = clash_;
        } else if (SaberBase::Lockup() == SaberBase::LOCKUP_NONE) {
          config = normal_;
        } else {
          config = lockup_;
        }
      } else {
         config = normal_;
         config.intensity_base = 0;
         config.intensity_rand = 0;
      }

I'm just not sure that "if (SaberBase::NumBlasts > 0)" is the best way to identify when a blast should be triggered.

Also wanting to change the retraction so it's like a normal saber blade. My current understanding is Fire Blade basically plays an animation of random colors travelling up the blade, and on retraction, the animation stops adding new colors and lets the existing ones finish travelling. What I'd like to do instead is, when retraction is triggered, start lowering the num_leds variable (or some temporary copy of it) while maintaining the animation, so the fire just travels a shorter distance each iteration until it stops emitting entirely.

SaberBase::NumBlasts > 0 will activate the blast for a rather long time, which might be ok, but it's probably better to do something like:

Saberbase::NumBlasts > 0 && micros() - SaberBase::getBlast(0).start_micros < 300000

(adjust the 300000 to the number of micros you actually want.)

For the retraction, it might be better to hack up a version of the fire style that fits he run()/getColor() pattern, that way you can just encapsulate it in
a InOutHelper<> template to get the retraction working the way you want to.


Offline KanyonKris

  • Padawan Learner
  • **
  • Posts: 72
  • Um...Hello?
Github ?
« Reply #145 on: December 04, 2017, 01:25:33 PM »
Looks like the last code commit to GitHub was early September. Are you not using GitHub anymore as your code repository? I'm OK pulling the latest firmware from your website, but just want to know what your plan is for managing the code.

Offline Kouri

  • No Force
  • *
  • Posts: 39
  • ~
Re: TeensySaber Software Discussion
« Reply #146 on: December 04, 2017, 04:27:36 PM »
Ehhhhh, this is still beyond me.

Put the re-writing to a hold and just used the existing blade code to whip up a new blade style in my config.

Changed the fire configs to bump up speed and minimum brightness while preventing it getting too yellow:
Code: [Select]
// Fire speed, valid values are 1 - 10
#define FIRE1_SPEED 3 //default 2
// How long to wait before firing up crossguards.
#define FIRE1_DELAY 800

// Each of these have three values: A, B, C
// A = non-random intensity
// B = random intensity
// C = cooling
// The first two control temperature, and as we add
// A + rnd(B) to the base of the blade each animation frame.
// The second controls how rapidly the fire cools down

// This is used during normal operation.
//#define FIRE1_NORMAL 0, 1000, 2
#define FIRE1_NORMAL 150, 900, 2

// This is used when a clash occurs
//#define FIRE1_CLASH  3000, 0, 0
#define FIRE1_CLASH  3000, 1000, 0

// This is used during lockup.
//#define FIRE1_LOCKUP 0, 5000, 10
#define FIRE1_LOCKUP 0, 5000, 10

// Helper
#define FIRE1PTR(NUM, DELAY) \
  StyleFirePtr<RED, Orange, NUM, DELAY, FIRE1_SPEED, \
    FIRE1_NORMAL, FIRE1_CLASH, FIRE1_LOCKUP>()

And using a random-flicker main blade with fire crossguards to keep most of the blade effects.
Code: [Select]
{ "font01", "tracks/Intro.wav",
    StylePtr<InOutSparkTip<EasyBlade<RandomPerLEDFlicker<Rgb<160,0,0>, Rgb<255,32,0> >, WHITE>, 300, 800, YELLOW> >(),
    FIRE1PTR(1, FIRE1_DELAY),
    FIRE1PTR(2, FIRE1_DELAY)
  },

Going to try and figure out how to mess with the single-button input so it's hold-while-on to Shutoff and tap-while-on for Blaster Block.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: Github ?
« Reply #147 on: December 04, 2017, 09:25:09 PM »
Looks like the last code commit to GitHub was early September. Are you not using GitHub anymore as your code repository? I'm OK pulling the latest firmware from your website, but just want to know what your plan is for managing the code.

I actually use CVS to manage the code, and then mirror the code to github.
Unfortunately I sometimes forget to do the mirroring, sorry about that.
I have mirrored all the latest changes now. Please remind me if I forget again.

Offline Kouri

  • No Force
  • *
  • Posts: 39
  • ~
Re: TeensySaber Software Discussion
« Reply #148 on: December 06, 2017, 09:25:48 AM »
Looking like three fire blades put a bit too much stress on Teensy. Really hard clashes, or a series of consecutive clashes pause the fire animation while the effect processes.

I'll try rewiring the hilt to get both crossguard's on one data pin and see how things work with just two blades.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: TeensySaber Software Discussion
« Reply #149 on: December 06, 2017, 10:31:26 AM »
Looking like three fire blades put a bit too much stress on Teensy. Really hard clashes, or a series of consecutive clashes pause the fire animation while the effect processes.

I'll try rewiring the hilt to get both crossguard's on one data pin and see how things work with just two blades.

That's weird, and it's not supposed to happen.
Are you sure it's not the "Blast" effect, because that one is pretty slow right now.
If that's not it, then something weird is going on, because running the fire blades takes exactly the same amount of processing power weather a clash is in effect or not.
Another thing to check is that each of BladeFirePtr<> calls has a different blade number argument. Not having that causes slowdowns.  (If you don't know what that is, just post your config file and I'll check for you.)

The last possibility is that something bad happens with hard clashes. Maybe the SD card gets wiggled to much? Maybe the power drops? Maybe the communication with the motion chip goes wonky for a little? Maybe the blade connector gets disconnected?

When these problems occur, does it affect all blades equally? Does it affect the sound as well? How long does it last?

 

retrousse