pydrake | Python implementation of the Drake equation | Time Series Database library

The code is a slightly modified version of this example here [...]

Unfortunately, this is not accessible to me (I'm not sure if this is your drive, or if the transition to DeepNote changed things). Can you post a link directly to the course notes? e.g. http://underactuated.csail.mit.edu/acrobot.html#cart_pole

As I understand this is just a building block for the "prototyping" and designing a suitable controller, is this correct?, is SymbolicVectorSystem still needed if there is a real robot?.

The choice is ultimately up to you and your application. SymbolicVectorSystem may express what you need initially, but your needs may extend beyond what it can (easily) express.

Now that I am happy with the controller, I would like to deploy this controller to a ROS2 robot. [...]

There are a few examples of this using the Systems Framework, some in Drake proper, others in downstream projects, but understandably it may be hard to locate them.

Some examples in Drake itself, though using LCM, not ROS2, though:

• https://github.com/RobotLocomotion/drake/tree/v1.1.0/examples/manipulation_station - most notably, see manipulation_station_hardware_interface.cc
• https://github.com/RobotLocomotion/drake/tree/v1.1.0/examples/kuka_iiwa_arm

Some examples in downstream projects; also primarily using LCM:

• From DAIR Lab
  • https://github.com/DAIRLab/dairlib/blob/9d9d8d02c/examples/kuka_iiwa_arm/iiwa_controller_demo.cc
  • https://github.com/DAIRLab/dairlib/tree/9d9d8d02c/examples/Cassie
• From Dexai
  • https://github.com/DexaiRobotics/drake-franka-driver/tree/cf3b20ef - this is moreso the "lower level" driver, but with very advanced features for robot arm control

As a small side note, some of us at TRI, w/ help from OpenRobotics, are (slowly) developing some ROS2 interfaces for Drake; you can see some of the progress here: https://github.com/RobotLocomotion/drake-ros/tree/develop
Some caveats:

• This is very experimental and has not yet been vetted (to any extent) on our side.
• Our primary customer is ourselves in this case, so it may not fit your use case well at this point in time.

I ran the code you linked.

There were a bunch of errors in there that needed to be fixed before it could be run, and it's clear that you're running on an older version of drake (still importing from attic which is long removed). Perhaps the new version will give you better error messages?

The one change that could have been more mysterious in an older version is that you were calling SetPositions with the wrong context. I've changed it to use the plant_context, not context: plant.SetPositions(plant_context, object_instance, [0, 0, 0, 1, 0, 0, 0]). With that fix (and fixing/updating the imports), that file runs fine for me.

didn't actually have any runnable code. So I'm not sure what I'm supposed to see there.

The current recommended answer is to use symbolic::Expression instead of AutoDiffXd when you need more than one derivative. While all of our C++ code should work if it was compiled with AutoDiffX to provide second derivatives, we currently don't build those as one of our default scalar types in libdrake.so.

I suppose you write your constraint using a python function. I would suggest to write this python function to handle both float and autodiffxd, so something like this

You've created a station_context and set it to the random poses, but then you don't use it anywhere. When you create the simulator, it is creating another Context (with the default values), which is getting published when you call AdvanceTo.

The solution here, I think, is to not create your own station_context, but do e.g.

The complaint is about the C++ standard library, i.e., libstc++ and its headers. The Clang compiler itself seems to be installed correctly, but it's looking for the GCC standard C++ library, and failing.

The problem might be if you have GCC 10 installed (or partially installed).

Does the https://github.com/RobotLocomotion/drake/issues/15652 advice help? Specifically:

Good news. As of this morning, you no longer have to use the setup_underactuated, and can install with pip, e.g. via

While I'm not familiar with Drake/PyDrake, any autodiffing program requires functions be implemented in a way that their derivatives are known. It seems that PyDrake is inspecting your code, identifying functions it knows autodiff versions of (e.g., np.arctan2) and replacing them with those versions. It looks like this is the list of functions PyDrake has implemented, so you may want to refer to this list rather than use trial and error. Oddly enough, arctan is there as well as arctan2. I think there may be an additional problem here, specifically that arctan(y/x) is not differentiable everywhere, whereas arctan2(x, y) is designed to fix that. See these plots of arctan(y/x) and arctan2(x, y) as examples.

Regardless, for mathematical reasons you probably want to be using arctan2 to find that angle, unless you know it's restricted to a certain range.

In my real use-case, I need to apply the same constraint to multiple timesteps in a trajectory, so I think it would be helpful to create the symbolic function once when I call AddConstraint for the first timestep and then all subsequent timesteps shouldn't have to re-create the symbolic function, I can just use the cached version and apply it to the relevant variables. The expression involves a Cholesky decomposition of a covariance matrix so there are a lot of constraints being applied.

I would strongly encourage to write this constraint using a function evaluation, instead of a symbolic expression. One example is that if you want to impose the constraint lb <= my_evaluator(x) <= ub, then you can call it this way