Tests failing due to PeriodicController issue #113
Comments
|
Probably related. The big change was: Anything that didn't rely on internal details should be fine, but anything that did grab internal details needs to know now that |
|
FWIW, the best thing would be for it not to be separate types for min vs max heaps, but 🤷♂ for now this works. |
|
I don't immediately see why you'd get an issue since the implementation detail should only be changing what happens when integrating in reverse time. |
|
I'm not entirely sure what MeshCat.jl is, but it's giving me install issues: (v1.1) pkg> dev RigidBodySim
[ Info: Path `C:\Users\accou\.julia\dev\RigidBodySim` exists and looks like the correct package, using existing path
Resolving package versions...
ERROR: Unsatisfiable requirements detected for package WebIO [0f1e0344]:
WebIO [0f1e0344] log:
├─possible versions are: [0.1.0-0.1.10, 0.1.12, 0.2.0-0.2.8, 0.3.0-0.3.4, 0.4.0-0.4.2, 0.6.0-0.6.2, 0.7.0, 0.8.0-0.8.1, 0.8.3-0.8.9, 0.8.11] or uninstalled
├─restricted to versions 0.2.6-* by RigidBodySim [e61f16d8], leaving only versions [0.2.6-0.2.8, 0.3.0-0.3.4, 0.4.0-0.4.2, 0.6.0-0.6.2, 0.7.0, 0.8.0-0.8.1, 0.8.3-0.8.9, 0.8.11]
│ └─RigidBodySim [e61f16d8] log:
│ ├─possible versions are: 1.3.0 or uninstalled
│ └─RigidBodySim [e61f16d8] is fixed to version 1.3.0
├─restricted by compatibility requirements with Atom [c52e3926] to versions: [0.8.1, 0.8.3-0.8.9, 0.8.11]
│ └─Atom [c52e3926] log:
│ ├─possible versions are: [0.1.0-0.1.1, 0.2.0-0.2.1, 0.3.0, 0.4.0-0.4.6, 0.5.0-0.5.10, 0.6.0-0.6.17, 0.7.0-0.7.15,
0.8.0-0.8.8, 0.9.0-0.9.1, 0.10.0-0.10.1] or uninstalled
│ └─restricted to versions 0.10.1 by an explicit requirement, leaving only versions 0.10.1
└─restricted by compatibility requirements with MeshCat [283c5d60] to versions: [0.1.8-0.1.10, 0.1.12, 0.2.0-0.2.8, 0.3.0-0.3.4, 0.4.0-0.4.2, 0.7.0] — no versions left
└─MeshCat [283c5d60] log:
├─possible versions are: [0.0.1-0.0.3, 0.1.0-0.1.2, 0.2.0-0.2.3, 0.3.0, 0.4.0, 0.5.0, 0.6.0, 0.7.0] or uninstalled ├─restricted to versions * by RigidBodySim [e61f16d8], leaving only versions [0.0.1-0.0.3, 0.1.0-0.1.2, 0.2.0-0.2.3, 0.3.0, 0.4.0, 0.5.0, 0.6.0, 0.7.0]
│ └─RigidBodySim [e61f16d8] log: see above
└─restricted by compatibility requirements with MeshCatMechanisms [6ad125db] to versions: [0.2.1-0.2.3, 0.3.0, 0.4.0, 0.5.0, 0.6.0, 0.7.0]
└─MeshCatMechanisms [6ad125db] log:
├─possible versions are: [0.0.1-0.0.6, 0.1.0-0.1.1, 0.2.0-0.2.1, 0.3.0, 0.4.0, 0.5.0] or uninstalled
└─restricted to versions 0.1.1-* by RigidBodySim [e61f16d8], leaving only versions [0.1.1, 0.2.0-0.2.1, 0.3.0, 0.4.0, 0.5.0]
└─RigidBodySim [e61f16d8] log: see above |
|
Thanks, Chris, that'll make it easy to fix on this end. FWIW, removing the |
|
I'm having the same issue as Chris, unable to install the package. Does this issue require a new commit or can I still use the current version somehow? |
|
@sn3akyLynx, are you also using Juno? |
Yes, Atom with Juno. It has worked earlier. |
|
I personally think that Juno's design decision of installing its packages next to the user's packages is very unfortunate, as it can lead to these kinds of situations (I've complained about this before, see JunoLab/Juno.jl#265). However, I'll see what I can do on Sunday. |
|
@ChrisRackauckas, it turns out that the |
tkoolen
added a commit
that referenced
this issue
Oct 7, 2019
Pass GUI callback into `ODEProblem` ctor instead of into `solve` function, since the callback passed into the `ODEProblem` ctor is now simply replaced with the one passed into `solve`, instead of being merged into a `CallbackSet` (SciML/OrdinaryDiffEq.jl#919).
|
It solved a bunch of requests with the ensemble system to allow for keyword arguments to be propagated if passed into the problem types. Since the callback handling wasn't actually documented, I searched out for any uses and didn't find any, so we made it line up with the other keyword arguments in the DiffEqBase 6.0 change. We should probably have all of the keyword arguments stored in the problems act similarly, but if we need a keyword argument to restore this behavior we can add it (and document it this time) |
|
Thanks. Although it conceptually makes sense to me to handle all keyword arguments the same, I think that having the problem's keyword arguments be silently overwritten by the I'd personally treat all arguments the same, but with the consistent strategy of 'merge where it makes sense, error otherwise, never overwrite'. If that conflicts with the ensemble system requirements, I'd add an additional A new kwarg like |
|
I think I have run into this issue when I updated from SciML/[email protected] to SciML/[email protected]. It may be due to SciML/DiffEqCallbacks.jl#79. Below is a minimal working example that is throwing the using RigidBodyDynamics
using RigidBodySim
mechanism = rand_chain_mechanism(Float64, [Revolute{Float64} for i = 1:8]...)
state = MechanismState(mechanism)
control! = (τ, t, state) -> τ .= 0.0
controller = PeriodicController(similar(velocity(state)), 0.01, control!)
dynamics = Dynamics(mechanism, controller)
tspan = (0.0, 5.0)
ode_problem = ODEProblem(dynamics, state, tspan)
sol = RigidBodySim.solve(ode_problem, Tsit5(), abstol = 1e-9)For anyone who might run into this, my current dirty workaround is: ] add DiffEqCallbacks@2.13.0; pin DiffEqCallbacks |
|
Thanks for the MWE. I can try and fix since it is my fault. |
|
Fixed in #126 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First failure: https://travis-ci.org/JuliaRobotics/RigidBodySim.jl/jobs/583088525#L541-L548
Possibly related to SciML/DiffEqCallbacks.jl@46cd2b2, though there have been builds with version 2.8.0 of DiffEqCallbacks that passed.
The text was updated successfully, but these errors were encountered: