jeff-winn / nemesis-mod Goto Github PK

The pairing process needs a display to show the pairing value for confirmation by the user on their device.

Without this, the pairing process does not use a secure channel and the blaster never identifies as having been paired (even if pairing has occurred).

To secure the blaster, it must be able to identify whether the connected device has successfully negotiated the pairing process.

The Bluefruit LE MCU should be better utilized by handling communication for:

• Diagnostic data
• Trim settings for zero
• Configuration of the belt speed and flywheel speed

As a user, I need to know when the blaster is close to running out of power.

This will need to support two independent features:

• Kill switch (shuts down the blaster motors)
• GATT characteristic for battery level

Also, this must support 3S along with 2S LiPo (optional).

To ensure the boards do not get burned out by accidental connections being mismatched, a custom board should be manufactured and mounted within the blaster.

There's a very small gap whereby the rev trigger can be released before the firing trigger. When this happens, the feed controller continues on until the rev trigger is pulled, released, and pulled a second time.

The flywheel and feed controllers both contain values that determine the motor speeds at the various MotorSpeed enum values.

These values need to be optimized for best case scenarios to ensure proper operation. Specifically the belt drive when on max setting is so fast the rounds just bounce out of the belt and the agitator throws them back up into the hopper.

The current sensing function is much too rapid to occur over a GATT characteristic and only occurs via notifications of a change.

As such, this should likely occur over UART for more constant updates if turned on.

The on/off switch should likely still be a characteristic so the power isn’t being wasted with nothing listening.

The following values are the expectations on the different flywheel speeds supported by the blaster:

• Kid: 80-85 FPS (this should match the normal Elite darts)
• Normal: 90-100 FPS (this should match the factory speeds used for the Nerf Rival series)
• Ludicrious: Hopefully this will reach 130ish FPS

The kid and normal levels should be determined by a chronograph and have the settings adjusted accordingly for the out of the box configuration to reach these target values.

The following documentation needs to be updated from the vendors:

• SAMD21 needs to be SAMD51
• The 5V regulator is missing documentation

As a user, I would like the ability to set my own pin for the Bluetooth connection bonding without having to compile the software myself. Because the current mechanism requires the use of the FRAM chip, and the difficulty to set it up is high having an externalized SD card I can plug into my computer to set the value in would be extremely helpful.

The LiPo pack will need a voltage monitor attached to a kill switch on the firing loop.

This ensures the battery stays within a safe operating voltage to prevent it from being damaged.

A command must be added for Bluetooth based remote deauthorization of the blaster. This addresses of the scenario whereby the control of the blaster is lost and a new unauthorized operator is now in control.

The hopper lock switch needs to be added to the design. The initial idea would just use an interrupt based software lock to prevent the blaster firing without the hopper installed.

With only one set of flywheels getting the rounds up to speed is causing the “yellow dust” effect whereby the rounds are being shredded by the flywheels while firing.

Perhaps using a 2 stage setup to get the rounds up to speed would reduce this effect.

The mainboard needs to be modified to support the nRF52 Bluefruit LE mainboard with ARM M4F chipset.

See:
https://www.adafruit.com/product/3406

As a user being able to swap out equipment is helpful for reducing cost. The current values used by the PWM signals are specific to the motor driver being used.

Rather than using a hard value in the code, use a multiplier instead with the actual value coming from the config file on the SD card.

Need to add a USB power multiplexer to handle power switching and external programming support for the blaster while it's pieced together.

Potential product:
https://www.pololu.com/product/2596
https://www.adafruit.com/product/3258

The panel mount could be used to plug into the multiplexer, and use the second pins to receive power from 5V power regulator. This option would also require having a USB Micro B breakout cable connect from the output pins into the Feather USB Micro B.

There needs to be a GATT characteristic added which supports read, write, and notify when the blaster is being fired and revved.

This will allow remotely firing the blaster from secondary positions on the battlefield.

The arduino cli may be hiding which c++ version is being applied to sonar during the scanning process, or the ide is applying the wrong standard for the c++ extension.

This should match up so the sonar findings are accurate to the version of c++ being used.

As a user, having the ability to change the speed while firing could be very helpful. I would like the blaster to recognize changes to settings while I'm using the blaster to fire rounds down range.

The nrf52832 may be experiencing issues with the process freezing due to the communication received from the client.

Allowing the Bluetooth processing to occur on a secondary board should alleviate the main processor from having to handle both functions.

This should:

• Introduce an M4 express and move the main logic to this sketch
• Replace the nrf52832 with an nrf52840 express

As a user, constantly having to reconfigure the blaster would be extremely annoying.

I would like to have a config section for profiles where I can setup the configuration for speed, trim, etc and have it persisted so I can just change to that profile.

Not entirely sure what the source of the problem is however here are the symptoms:

• Both flywheel motors stop turning (most commonly seen after extended use)
• Single flywheel motor stops turning (usually results in the second flywheel motor seeing a significant speed increase)
• Belt drive motor stops turning

As a user, it’s very valuable to me to see when the board is actively processing commands. As such it would be helpful if th LED on the NRF52 was lit when inbound and outbound data is waiting to be processed.

As a consumer faster is always better. The 3S LiPo currently in use is at capacity for how fast the motors can go.

Introducing a single stage brushless setup would continue to improve the FPS at the barrel.

This means:

• A brushless ESC must be introduced
• The motors at the flywheels need to be brushless

The motors may need to be lower RPM and larger to produce more torque to get the inertia overcome.

The flywheel speed currently requires a reset of the trigger to take effect. The expectation is it should be immediate.

Currently the authentication lock is disabled but in order to enable speeds higher than the default the operator must have a means of authenticating themselves.

Possibilities:

• Bluetooth and a connected app with fingerprint recognition
• Built in biometric fingerprint reader

For deployments to devices, having all of the arduino tools installed, ensuring all the dependencies are being installed can be quite cumbersome for someone just wanting to use the product. The feather products come with a bootloader that accepts UF2 files to aid deployment by dragging and dropping the files onto the device using the USB cable without any additional software.

As a user, this would greatly increase adoptability for ease of deployment.

Here's a couple helpful links I found:

• https://github.com/microsoft/uf2/blob/master/utils/uf2conv.md
• https://learn.adafruit.com/adafruit-feather-m4-express-atsamd51/uf2-bootloader-details
• Seeed-Studio/Seeed_Arduino_USBDISP#7

Hierarchical sheets would likely clean up the schematic as it is quite cluttered right now.

The firmware is getting pretty out of date, it needs to get upgraded along with any dependencies that might be using a newer version.

Not sure which this is but if the settings are changed rapidly, the blaster can either stop logging that the blaster is revving and firing, or the blaster is actually rendered inoperable.

To ensure only a single Bluetooth connection can be established to the blaster, the advertising packets should only be started if the device is not already paired.

Along with this, pressing the reset button should also clear the Bluetooth controller bonds as well as the app data.

Perhaps this also means the reset should be done outside the app control?

The 5V voltage regulator needs to be installed between the 18v18 motor shield and the Feather.

https://www.pololu.com/product/2843

Also consider adding a USB Power Multiplexer to allow the battery pack to remain connected while also allowing a panel mounted USB port allowing external reprogramming of the device. This will still require the 5V voltage regulator if this option were implemented.

https://www.pololu.com/product/2596

As a new c++ developer there is likely a lot of things c++ can do that I don’t know I should not do it.

Having a tool in place to scan the code could be helpful in both keeping the code tidy along with improving my knowledge of the language.

The Pololu G2 18v17 motor driver needs to be installed to drive the belt motor.

With the MCU being housed inside the blaster, the bluetooth light does not do much aside from waste power.

It should be disabled.

The settings currently supported by the blaster only a few are remotely configurable using the BLE characteristics. The remaining settings need to be configurable over this mechanism.

The current setup using separate Bluetooth services away from the areas that own the data causes difficulty for loading the data into the characteristics as well as the need for the callback.

The characteristics should live within their respective controllers along with the callback such that the static instance of the controller could be used to change the value.

The Bluetooth PIN should come from the master during initialization of the BTReadyCommand.

Currently it’s been hard coded within the Bluetooth sketch.

Moving this to the master will allow separation of the config when it comes from the SD card.

The current hardware configuration uses the USB pin and GND pins to power the device using the Pololu 5V 500mA step-down voltage regulator.

This regulator should be switched out for a 3.3v 500mA step-down voltage regulator and use a JST PH 2-pin connector to connect to the MCU.

Example products:

• Voltage Regulator
• JST PH 2-pin Connector

With the Bluetooth functionality separated into a secondary board, the data handled there must be passed to the mainboard for processing.

It should:

• Initialize as a slave on the bus while the mainboard is master.
• Receive the data and route the information into a transfer buffer.
• Flag the mainboard it has data waiting through an interrupt pin.
• Have the mainboard pull the data in.
• Have the mainboard process the command received.

The hardware does not support EEPROM or FRAM for storage of configuration settings that persist beyond restart of the device.

The blaster needs to be able to transmit diagnostic data to the iOS companion application for monitoring battery health, current output, etc.

The following data points are required from Motor_Driver_1:

• M1CS
• M2CS

The following data points are required from Motor_Driver_2:

• CS

More information may be added after issue #10 has been closed and something is monitoring the battery health via the balance connector.

Since the hopper lock cuts power to the MCU, whenever the hopper is open the restarting of the MCU causes the settings the shooter is currently using (feed and flywheel speeds) to be reset to their startup configuration.

When used in a battle, this will definitely be an issue with rapidly refilling the rounds in the hopper and resuming play.

The pairing pin for the Bluetooth connection is currently hard coded, this means someone has to know how to recompile and deploy to change the value.

This value should likely come from the master device and passed into the Bluetooth device during init prior to starting advertise.

There needs to be a command which will set the authentication data on the device if none is present, or require the operator to authenticate prior to allowing the authentication data to be modified.

The BLEBas service can be used to display battery levels on a device.

Determining the battery voltage at 3.4V per cell at 0% and 4.2V at 100% would be a good indication.

As a user, having firmware i can rely upon working consistently over time is extremely important.

The quality gate shows failure because the test coverage is at 0%.

As a developer, having the state of the blaster persisted and reloaded upon startup should ensure consistent operation.

This will require a blaster.stateconfig file on the SD card that is read during startup.