Trajectory Generation V2
Rewrite of the trajectory generation to properly balance robot rotation and translation, and respect individual module limits. This isn't time optimal like Choreo, but should be significantly more accurate and hopefully allow PathPlanner paths to "just work" with little to no path tuning.
Still has a lot of issues that need to be ironed out and optimizations that need to be made. Some of these issues are due to the distribution of path samples along each spline segment. These will be fixed in a future PR that will dynamically sample the path based on distance and amount of rotation. Should be good enough for now with future PRs to improve it.
- [x] Implement POC for new generation in GUI
- [x] Add more motor torque curves for popular motors and current limits
- [x] Support differential drive robots
- [x] Fix issues and optimize (from testing, the dynamic path resolution PR should alleviate issues with module path discontinuities)
- [x] Display GUI warning when a trajectory fails to generate
- [x] GUI test coverage
- [x] PPLib Java
- [ ] PPLib C++
- [ ] PPLib Python
- [ ] Test on real robot
- [ ] Documentation
Codecov Report
Attention: Patch coverage is 88.17097% with 119 lines in your changes missing coverage. Please review.
Project coverage is 85.35%. Comparing base (
448e433) to head (4d4feac). Report is 1 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #694 +/- ##
==========================================
- Coverage 85.51% 85.35% -0.16%
==========================================
Files 78 83 +5
Lines 6867 7445 +578
==========================================
+ Hits 5872 6355 +483
- Misses 995 1090 +95
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I got bored and did some messing around with this, so far it looks really nice. Not sure if this is already a known issue or not, but it looks like if you change to a different motor and current that causes trajectory generation to fail, this error shows up when you open the path again:
flutter: ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
flutter: │ dependOnInheritedWidgetOfExactType<_ScaffoldMessengerScope>() or dependOnInheritedElement() was called before _SplitPathEditorState.initState() completed.
flutter: │ When an inherited widget changes, for example if the value of Theme.of() changes, its dependent widgets are rebuilt. If the dependent widget's reference to the inherited widget is in a constructor or an initState() method, then the rebuilt dependent widget will not reflect the changes in the inherited widget.
flutter: │ Typically references to inherited widgets should occur in widget build() methods. Alternatively, initialization based on inherited widgets can be placed in the didChangeDependencies method, which is called after initState and whenever the dependencies change thereafter.
flutter: ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
flutter: │ #0 StatefulElement.dependOnInheritedElement.<anonymous closure> (package:flutter/src/widgets/framework.dart:5713:9)
flutter: │ #1 StatefulElement.dependOnInheritedElement (package:flutter/src/widgets/framework.dart:5756:6)
flutter: │ #2 Element.dependOnInheritedWidgetOfExactType (package:flutter/src/widgets/framework.dart:4774:14)
flutter: │ #3 ScaffoldMessenger.of (package:flutter/src/material/scaffold.dart:149:51)
flutter: │ #4 _SplitPathEditorState._simulatePath (package:pathplanner/widgets/editor/split_path_editor.dart:747:27)
flutter: │ #5 _SplitPathEditorState.initState (package:pathplanner/widgets/editor/split_path_editor.dart:113:5)
flutter: │ #6 StatefulElement._firstBuild (package:flutter/src/widgets/framework.dart:5611:55)
flutter: │ #7 ComponentElement.mount (package:flutter/src/widgets/framework.dart:5456:5)
flutter: ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
flutter: │ ⛔ Dart Error
flutter: └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Yeah I think I ran into that before. The goal is to never have generation fail but it has a lot of issues currently when a module needs to turn in place. From what I’ve seen so far that seems to be the root cause of generation failing or the robot going slower than necessary in pretty much every case I’ve noticed. So once I hopefully get that figured out I can just get rid of the failure notification altogether.
I have a question regarding API and coordinate systems next year. Is the plan to keep everything blue origin? I was a huge fan of it this year as it didn't require any sort of conversion between odometry and vision.
Yes, that will stay the same. The only thing that will change is the path flipping function if it is a rotationally symmetric field.
Awesome, I was very happy with the standardized coordinate system this year, glad that it will continue