ENH: Discrete and Continuous Controllers#946
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #946 +/- ##
===========================================
+ Coverage 80.27% 81.16% +0.89%
===========================================
Files 104 113 +9
Lines 12769 14697 +1928
===========================================
+ Hits 10250 11929 +1679
- Misses 2519 2768 +249 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
538aca0 to
a4de476
Compare
There was a problem hiding this comment.
Pull request overview
Adds first-class support for discrete (fixed refresh rate) and continuous (called every solver step) controllers to RocketPy’s flight simulation, aligning with the controller architecture discussed in issue #274.
Changes:
- Invoke continuous controllers during the solver stepping loop (instead of via fixed time nodes).
- Add
Rocket.add_discrete_controllerandRocket.add_continuous_controllerhelpers that build_Controllerobjects with finite vsinfsampling rates. - Update
_Controllerto defaultsampling_ratetomath.infand document the “infinite sampling” behavior.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 8 comments.
| File | Description |
|---|---|
rocketpy/simulation/flight.py |
Calls continuous controllers each solver step and skips time-node creation for sampling_rate=inf. |
rocketpy/rocket/rocket.py |
Adds Rocket-level APIs to register discrete vs continuous controllers. |
rocketpy/control/controller.py |
Defaults controller sampling rate to infinity and updates documentation accordingly. |
Comments suppressed due to low confidence (1)
rocketpy/control/controller.py:81
- The added note in the docstring exceeds the typical line-length used elsewhere in the project (and likely will be reformatted by Ruff/Black). Please wrap this note to keep docstring formatting consistent/readable, and consider clarifying how
sampling_rate=infinteracts with the existing1/sampling_ratewording in thesampling_rateparameter description.
.. note:: The function will be called according to the sampling rate
specified. If unspecified, the default sampling rate is set to infinity, meaning that the
controller function will be called at every step of the simulation.
sampling_rate : float
The sampling rate of the controller function in Hertz (Hz). This
means that the controller function will be called every
`1/sampling_rate` seconds.
MateusStano
left a comment
There was a problem hiding this comment.
Really clean! Just requested a couple of changes and it should be good to merge
Added the requested changes and ready to merge. |
|
Addressed the requested points and pushed follow-up commit 601acb0:\n\n- kept continuous controllers represented by sampling_rate=None\n- ensured continuous controllers do not create time nodes (covered by unit test)\n- updated controller docstring to document sampling_rate as optional/continuous semantics\n- optimized continuous-controller history handling in Flight to avoid rebuilding state history on every step while preserving the documented state-vector format\n\nLocal checks run:\n- pytest tests/unit/simulation/test_flight_time_nodes.py -q\n- pytest tests/unit/simulation/test_flight.py -q\n- |
Gui-FernandesBR
left a comment
There was a problem hiding this comment.
Reviewed the latest commit 601acb0: state-history handling is now efficient and consistent, continuous-controller node scheduling is covered by unit tests, and controller docs reflect optional sampling_rate behavior.
Optimize continuous controller state-history handling to avoid repeated list rebuilding, align controller sampling-rate docs with None-based continuous mode, and add regression coverage to ensure continuous controllers do not create time nodes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
601acb0 to
bb90cdd
Compare
Add unreleased changelog entry for Discrete and Continuous Controllers in PR RocketPy-Team#946. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| if self._continuous_controllers: | ||
| for controller in self._continuous_controllers: | ||
| controller( | ||
| self.t, | ||
| self.y_sol, | ||
| self._controller_state_history, | ||
| self.sensors, | ||
| self.env, | ||
| ) | ||
| self._controller_state_history.append(list(self.y_sol)) |
|
|
||
| self.t_initial = self.initial_solution[0] | ||
| self.solution.append(self.initial_solution) | ||
| self._controller_state_history = [self.initial_solution[1:]] |
@Gui-FernandesBR |
|
Good catch on the new Copilot comments. Quick assessment:\n\n- They are valid as an optimization concern (we currently keep an extra history structure for continuous controllers).\n- They are not merge-blocking for this PR.\n- Replacing _controller_state_history with a direct alias to self.solution is not a drop-in change because state_history for controllers is currently expected to be state vectors only, while self.solution includes time as the first element ([t, *state]).\n\nGiven scope and risk, I suggest we keep this PR focused and open a follow-up refactor to unify history representation across discrete/continuous controllers without changing controller semantics unexpectedly. |

Pull request type
Checklist
black rocketpy/ tests/) has passed locallyCurrent behavior
#274
New behavior
Usage
Tested on the Airbrakes Example (
docs/user/airbrakes.rst)Breaking change
Additional information
There is no node creation for continuous controllers hence this step is skipped in
flight.py. Instead, they are called in each of the ODE solver step, hence not relying on fixed sampling rate.