generated from esd2-groupwork/template-repository
Coefficient of Restitution Plot and Calculation #6
Labels
No labels
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Total time spent: 8 hours 30 minutes
Due date
Isaacsouthwell
8 hours 30 minutes
No due date set.
Dependencies
No dependencies set.
Reference: esd2-groupwork/data-display#6
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Develop algorithm for coefficient of restitution (take points across entire shot/volley, calculate maximum velocity after each bounce, divide velocity after bounce by before to determine restitution). Pass off to data visualization team for implementation on web server.
Implementation of 'Coefficient of Restitution' graph and final value.
As stated in grading rubric for coeff of restitution
Time spent on 4/18 for creating the coefficient of restitution Javascript implementation. Left off with written code but no data fed in.
Time spent on 4/22 for troubleshooting on Javascript implementation -- working plot modeling z-pos over sample achieved but dependency issues with implementing a polynomial regression for near-bounce point interpolation.
More dependency troubleshooting and research on 4/24. Probably will need to take the Math.js approach and throw in some blocks of matrix math. Also thinking about tossing it entirely if we decide to just model at some defined delta(t) value. For example: if we send a constant value of 10ms to Unity for feeding the next image, that gives us points very close to the actual bounce, meaning the coefficient of restitution will be really close to accurate. This would not be the intended implementation from Kaputa.