fiduciary

Author Topic: TeensySaber Software Discussion  (Read 67138 times)

0 Members and 1 Guest are viewing this topic.

Offline Kouri

  • No Force
  • *
  • Posts: 39
  • ~
Re: TeensySaber Software Discussion
« Reply #150 on: December 06, 2017, 12:55:23 PM »
I'd actually gone back to the stock lightsaber.ino without Blaster or Slash code to verify it wasn't any of those additions.

It's all blades equally, and I think I've got the culprit. The lowered swing threshold is triggering way too many swing events. I can clash and rapidly swing to slow the animation and effectively freeze a clash mid-blade.

I'm thinking I need to add some sort of alarm to limit the number of swings per second.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: TeensySaber Software Discussion
« Reply #151 on: December 06, 2017, 03:59:04 PM »
I'd actually gone back to the stock lightsaber.ino without Blaster or Slash code to verify it wasn't any of those additions.

It's all blades equally, and I think I've got the culprit. The lowered swing threshold is triggering way too many swing events. I can clash and rapidly swing to slow the animation and effectively freeze a clash mid-blade.

I'm thinking I need to add some sort of alarm to limit the number of swings per second.

Normally swinging_ is set to true when a swing starts, and isn't set to false until the swing is over. New swings sounds aren't generated unless swinging_ is false.
Maybe your change messed that up somehow?


Offline Kouri

  • No Force
  • *
  • Posts: 39
  • ~
Re: TeensySaber Software Discussion
« Reply #152 on: December 06, 2017, 04:43:31 PM »
I literally just changed the "250" to "SWING_THRESHOLD". It shouldn't affect swing detection. I think you can verify the issue by dropping the threshold in your own lightsaber.ino to 150 or less. It was never apparent before because 250 is a ridiculously high swing threshold that made it hard to trigger a single swing event, let alone a series of recurring swings.

The code basically checks "if moving faster than threshold, say we're swinging and disable new swings. If under threshold, say we're not swinging and re-enable swings" which sounds great. The problem is with a low threshold, anything that's going to rock the saber back and forth, like a really hard impact, or just swinging back and forth, is going to vary speed. Say I'm swinging left and right - eventually I'm going to have to stop moving left to move right, so the saber stops moving left - if only for a fraction of a second, so that it can start moving right, and at that moment, speed is low enough to re-enable swing sounds.

I think some sort of swing timer variable will fix the issue. Basically, somewhere declare a timer variable:

Code: [Select]
swing_timer = 0;
Then adjust the swing code to check that the timer is 0, and set the timer when a swing starts:

Code: [Select]
if (speed > SWING_THRESHOLD) {
      if (!swinging_ && state_ != STATE_OFF && swing_timer == 0) {
        swinging_ = true;
        swing_timer = 20; //arbitrary value
        Play(&swng);
      }
    } else {
      swinging_ = false;

And then somewhere else, count down the timer.
Code: [Select]
if (swing_timer > 0) {
      swing_timer--;

I'm just not sure if that's the best way to go about making a timer for this little microcontroller. I've only ever done game development for PC where there's plenty of CPU and memory to spare.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: TeensySaber Software Discussion
« Reply #153 on: December 06, 2017, 05:29:48 PM »
I literally just changed the "250" to "SWING_THRESHOLD". It shouldn't affect swing detection. I think you can verify the issue by dropping the threshold in your own lightsaber.ino to 150 or less. It was never apparent before because 250 is a ridiculously high swing threshold that made it hard to trigger a single swing event, let alone a series of recurring swings.

The code basically checks "if moving faster than threshold, say we're swinging and disable new swings. If under threshold, say we're not swinging and re-enable swings" which sounds great. The problem is with a low threshold, anything that's going to rock the saber back and forth, like a really hard impact, or just swinging back and forth, is going to vary speed. Say I'm swinging left and right - eventually I'm going to have to stop moving left to move right, so the saber stops moving left - if only for a fraction of a second, so that it can start moving right, and at that moment, speed is low enough to re-enable swing sounds.

I think some sort of swing timer variable will fix the issue. Basically, somewhere declare a timer variable:

Code: [Select]
swing_timer = 0;
Then adjust the swing code to check that the timer is 0, and set the timer when a swing starts:

Code: [Select]
if (speed > SWING_THRESHOLD) {
      if (!swinging_ && state_ != STATE_OFF && swing_timer == 0) {
        swinging_ = true;
        swing_timer = 20; //arbitrary value
        Play(&swng);
      }
    } else {
      swinging_ = false;

And then somewhere else, count down the timer.
Code: [Select]
if (swing_timer > 0) {
      swing_timer--;

I'm just not sure if that's the best way to go about making a timer for this little microcontroller. I've only ever done game development for PC where there's plenty of CPU and memory to spare.


I'll try lowering the swing threshold and see if I have the same issue.
(Are you using plecter or NEC style font though?)

If you look carefullly you'll find plenty of examples of timers in the code.
The right way is usually to do something like this:   (swing_end_ is a uint32_t)
Code: [Select]
   if (speed > SWING_THRESHOLD) {
      if (!swinging_ && state_ != STATE_OFF && millis() - swing_end_ > 200) {
        swinging_ = true;
        Play(&swng);
      }
   } else {
      if (swinging_) {
        swing_end_ = mills();
        swinging_ = false;
      }
   }
   // avoid wrap-around
   if (millis() - swing_end_ > 10000) swing_end_ = millis() - 5000;

Another option would be to star the timer when the swing stops.

Offline KanyonKris

  • Padawan Learner
  • **
  • Posts: 72
  • Um...Hello?
Single button preset change
« Reply #154 on: December 06, 2017, 09:22:56 PM »
Stupid question: How do I change presets with a single button?

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: Single button preset change
« Reply #155 on: December 06, 2017, 10:36:47 PM »
Stupid question: How do I change presets with a single button?

I don't have a configuration option for changing what the buttons do, but it's not
terribly difficult to do in the code, just search for "case EVENTID" in lightsaber.ino.

Offline bobi-one

  • No Force
  • *
  • Posts: 43
  • Um...Hello?
Re: TeensySaber Software Discussion
« Reply #156 on: December 07, 2017, 12:03:36 AM »
One question about the templates (c++ in embeded is nightmare for me :D) Im Trying to do a custom preset that allows me to switch the color and font from the BLE App. I taught of doing it as separate implementation. But You might have already considered this idea while designing the whole class structure.

Secondly, I believe we need some persistence class, In order to save configuration in the eeprom for example. Its quite handy when going to Conventions and putting the blade plug will force you to browse through the presets over and over again to find the one you prefer for the event.

Regards,
Boyko

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: TeensySaber Software Discussion
« Reply #157 on: December 07, 2017, 12:31:40 AM »
One question about the templates (c++ in embeded is nightmare for me :D) Im Trying to do a custom preset that allows me to switch the color and font from the BLE App. I taught of doing it as separate implementation. But You might have already considered this idea while designing the whole class structure.

Secondly, I believe we need some persistence class, In order to save configuration in the eeprom for example. Its quite handy when going to Conventions and putting the blade plug will force you to browse through the presets over and over again to find the one you prefer for the event.

Regards,
Boyko

Unfortunately, I did not consider the need for dynamic configuration when I designed the blade configuration classes. However, I did think long and hard about it while working on the bluetooth stuff.

I haven't implemented anything yet, but my idea was to to implement support for reading the presets from a config file on the SD card.  Since I don't want to create an entire configuration language, the blade configuration would be as simple as a template name and a couple of colors/numbers.  The bluetooth configuration app would then update the settings by simply re-writing the configuration file.

The trick will be to provide a comprehensive list of name -> blade templates.
While using the eeprom does have some advantages (doesn't interfere with the sound for one thing) the SD card makes it a lot simpler to access and see what's going on, and it also makes it possible to edit the config file the old-fashion way.


Offline Kouri

  • No Force
  • *
  • Posts: 39
  • ~
Re: Single button preset change
« Reply #158 on: December 07, 2017, 08:34:56 AM »
Stupid question: How do I change presets with a single button?

While off, press and hold the power button and trigger a clash.

----

Prof, this is with the NEC fonts. I've a Kylo font I'll eventually use on the hilt, but for now, I'm using Naigon's "Testing Testing Testing" (FONTC in the Igniter Default package) to calibrate swing/slash thresholds.
« Last Edit: December 07, 2017, 08:40:34 AM 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 #159 on: December 09, 2017, 07:04:56 PM »
New teensysaber software version: 1.175

As usual, you can download the new version here: Teensy Saber OS

New features:

SubBlade - This let's you split up a string of neopixels into multiple blades
IgnitionDelay - Let's you delay the ignition of a blade, intended for kylo-style quillions.
ColorCycle - Meant for circles of neopixels, lights up a fraction of the circle and rotates
Makefiles - Let's you compile and install the code using "make" instead of the arduino IDE.
Support for up to 8 blades (crystal chambers and auxiliary LEDs are also blades)

There are additional instructions for how to use these features in the code, but feel free to ask questions here.

Offline KanyonKris

  • Padawan Learner
  • **
  • Posts: 72
  • Um...Hello?
MTP folders
« Reply #160 on: December 09, 2017, 10:25:13 PM »
MTP disk is not fully working for me.

I copied files and folder structure onto the SD card then put it into the Saberboard (V3). When I view the SD card via MTP I can see the files in the root directory and the folders, but when I go into a folder I see no files there nor can I see any subfolders.

When in an MTP connection I was able to create a folder but not copy any files to the SD card.

I am using Windows 7 (I saw a PJRC forum post that said maybe Windows 7 doesn't work, only Windows 10). And installed the latest Teensyduino.

Offline profezzorn

  • Mining Colony Members
  • Master Force User
  • *
  • Posts: 901
  • May the source be with you.
    • Hubbe's Corner
Re: MTP folders
« Reply #161 on: December 10, 2017, 12:39:12 AM »
MTP disk is not fully working for me.

I copied files and folder structure onto the SD card then put it into the Saberboard (V3). When I view the SD card via MTP I can see the files in the root directory and the folders, but when I go into a folder I see no files there nor can I see any subfolders.

When in an MTP connection I was able to create a folder but not copy any files to the SD card.

I am using Windows 7 (I saw a PJRC forum post that said maybe Windows 7 doesn't work, only Windows 10). And installed the latest Teensyduino.

Hmm, I thought I did some testing with windows 7, but that was a while ago, so I don't remember the results.
I'm going to try it again, but it may take a while since I'll be travelling over the holidays.


Offline bobi-one

  • No Force
  • *
  • Posts: 43
  • Um...Hello?
Re: TeensySaber Software Discussion
« Reply #162 on: December 11, 2017, 02:23:51 AM »
One question about the templates (c++ in embeded is nightmare for me :D) Im Trying to do a custom preset that allows me to switch the color and font from the BLE App. I taught of doing it as separate implementation. But You might have already considered this idea while designing the whole class structure.

Secondly, I believe we need some persistence class, In order to save configuration in the eeprom for example. Its quite handy when going to Conventions and putting the blade plug will force you to browse through the presets over and over again to find the one you prefer for the event.

Regards,
Boyko

Unfortunately, I did not consider the need for dynamic configuration when I designed the blade configuration classes. However, I did think long and hard about it while working on the bluetooth stuff.

I haven't implemented anything yet, but my idea was to to implement support for reading the presets from a config file on the SD card.  Since I don't want to create an entire configuration language, the blade configuration would be as simple as a template name and a couple of colors/numbers.  The bluetooth configuration app would then update the settings by simply re-writing the configuration file.

The trick will be to provide a comprehensive list of name -> blade templates.
While using the eeprom does have some advantages (doesn't interfere with the sound for one thing) the SD card makes it a lot simpler to access and see what's going on, and it also makes it possible to edit the config file the old-fashion way.

Lets make it the safe way - Sd card and eeprom. For example 1st boot will load configuration file to eeprom, as you can never trust  memory with a mechanical connection :D. I even believe when MTP is fully tested functional, that eMMC  chip will be the best thing to use in the future.
The other consideration is that you may program one hilt to act in certain way, but if you reuse the SD card to other hilt, you may  need completly diferent configuration - > SD provides default config, and user config stays in EEPROM.

One other thing is about the Bluetooth boards,
For the T1 diabetes society we use a clever board called xbridge which is basically a wixel and a HM-XX bluetooth board,
The MCU uses the AT commands to change the name and password  of the HM module, and same way can be done here. And on evry init will check if the connected Bluetooth module is correctly configured.


Offline Kouri

  • No Force
  • *
  • Posts: 39
  • ~
Re: TeensySaber Software Discussion
« Reply #163 on: December 11, 2017, 05:35:41 AM »
Well that multi-blade revision is most welcome. Going to see if I can mount a single NeoPixel somewhere on the hilt with style_charging so I don't need to dedicate an entire blade preset for power indication.

Offline KanyonKris

  • Padawan Learner
  • **
  • Posts: 72
  • Um...Hello?
Re: MTP folders
« Reply #164 on: December 11, 2017, 10:12:43 AM »
Hmm, I thought I did some testing with windows 7, but that was a while ago, so I don't remember the results.
I'm going to try it again, but it may take a while since I'll be travelling over the holidays.
Tried MTP with Windows 10 this morning. Worked. I could see all files in all folders, even 2 sub folders deep.
So it's a Windows 7 issue. I can work around this as I have access to some Windows 10 computers.

BTW, I'm enjoying building my own saber and tinkering with the code (mostly just configuration and presets). Cobbled the parts together over the weekend and (after some troubleshooting) saw the PL9823 blade "extend" for the first time and it was a thrill. Thank you for your documentation and excellent firmware.

One suggestion: It would be nice if you described the basic functions. Things like how to do a lock, blaster, force and drag - with 0, 1 or 2 buttons. How to change presets (with saber off, hold down the power button and tap the blade). Some of these were not obvious to me. I deduced some things from the code, but not all. You've added so many cool features over the firmware releases, it'd be a shame if people didn't know how to use them.

 

retrousse