ahalekelly / dettlaff Goto Github PK

https://www.rcgroups.com/forums/showatt.php?attachmentid=8524039&d=1450424877
Raymond
rpm-control branch

This happens when you use bidirectional dshot and PID and wifi at the same time:

assert failed: rmt_isr_handle_rx_done rmt_rx.c:505 (offset > rx_chan->mem_off)

Backtrace: 0x40083715:0x3ffbf4ec |<-CORRUPTED

ELF file SHA256: ca134528bf1404a7

Rebooting...

https://github.com/BrushlessPower/BlHeli-Passthrough

We've got a placeholder value for spin down logic in the flywheel proto; we should figure out how we want to use that and update the documentation with units and/or an explanation when we do.

@LL0W

Adrian

There's corrupted rpm data with bidirectional dshot, so we should store the timestamp of the last time each rpm value was updated, and only allow rpm value to update if the rate of change from the last update to the current value is less than a threshold

People will want / have been asking for all sorts of ux options like rotational switches, quick setting buttons, screens, dpads like the PewPew, etc

```Also we need an option to have a button that will jump to a specific fire mode instead of cycling through modes - should this be a parameter in each FireModeEntry, or a repeated value in ControlParams? Each button will need a pin and SwitchOrientation``

Originally posted by @ahalekelly in #2 (comment)

It would be pretty neat if the current firing mode could update on the web app; users could then have a couple picked out to switch between and do so with a tap.

We might need a special "updatable" proto message

BLE only natively supports packets as large as 512 bytes; NanoPB is calculating that the Blaster proto has a max size that exceeds 600 bytes (and I need to add support for independent RPMS for each motor, so it will get larger).

I need to look at the ESP32 library to see if it has any expected way to handle packets that are too large for one method; @ahalekelly can you check how your webBLE handles that?

If it's missing from either or they have incompatible mechanisms, we might need to implement our own version of that

Adrian

If the braking torque of the motor is not enough, you could apply reverse voltage instead of braking to stop it faster, or you could brake normally and reverse the motor if the pusher overruns and the cycle control switch becomes released

1. When cycle control switch is pressed, (maybe stop applying voltage to the pusher and wait a few ms to allow inductive field to decay faster than reverse polarity? should test whether this helps), then apply reverse polarity to pusher
2. After pusherReversePolarityDuration_ms time has passed, if cycle control switch is still pressed, remove reverse polarity and brake pusher
3. If pusherReverseOnOverrun config flag is set and cycle control switch is no longer pressed, maintain reverse polarity until switch becomes pressed again, then brake

I don't think we need a separate pusher control mode from the current PUSHER_MOTOR_CLOSEDLOOP mode, I think if you set duration to 0 and and the config flag to false then it would operate the same as the current mode?

It might be possible to automatically determine these variables through trial and error? Start with 0ms reverse polarity duration, and every time you see a pusher overrun, increase the duration by 1ms, up to some cap?

Turn off ESC and sleep Dettlaff when not in use
Reduce cpu speed from 240MHz?
Notify user when battery voltage is low and then turn off ESC and sleep Dettlaff
Make white LED default to off

Need to check whether pressing the trigger soon after startup prevents ESCs from arming

Also someone requested a switch to make the flywheels idle all the time

Ideally, we would have some way for a tournament organizer/staff to lock the fps (and rate of fire?) while still allowing the user to make and adjust firing modes.

This needs to

• Persist through a power cycle
  • both for legitimate battery changes and to foil bypass attempts
• Probably needs a timeout so that organizers don't need to publish said code or manually unlock devices
  • Doing this well could be challenging
    • A real time clock could let us set a timeout by wall clock time, but needs a battery that could complicate things
    • We could use clock time from the user's phone, but what happens if they take their phone offline and set the clock differently?
    • We could set up a server (/ serverless function?) that lets an organizer register their tournament's start time, end time, and limits, then lock the user's detlaff to that until their phone can query said server to see if it's okay to unlock?
      • This does mean someone could get stuck in a tournament lock if they leave early and can't undo it
• Does Detlaff need to periodically advertise its state, tournament locked or not?

This might be simple enough with a code entered though the web app

This would probably be handled better through an event-organizer-specific web app; We'll see how far that gets

PWM based on battery voltage to maintain a constant output voltage

https://github.com/Dlloydev/QuickPID
https://github.com/Dlloydev/sTune
Raymond
rpm-control branch

I think just a revSwitchIdle boolean parameter is sufficient, I don't think we need to support both a rev switch and an idle switch at the same time?

Daedher

Should this be supported in Dettlaff, or just do it in the ESC?

https://learn.sparkfun.com/tutorials/esp32-ota-updates-over-ble-from-a-react-web-application/all

The PCB has an I2C connector for a small OLED screen or other accessories (see the Narfduino Console), but I'm not currently planning on writing the UI for a screen. Lots of people seem to want it, this would be a good project for someone to take on as it's reasonably self-contained.