robomechanics / quad-sdk Goto Github PK

Provide a basic package structure where members can add project-wide functions and classes in a namespace-protected way.

• Separate branch
• Copy outline from estimator or package template

Separate roslaunch files into logical units (remote.launch, robot.launch should be wrappers around smaller launch files)

• Add doxy still comment to spirit_logger python scripts

Implement this library within spirit_utils.

Only do once other PRs are cleared.

Anyone could do this, really, but it would be nice to do it before it goes into the message so it only needs to be done once (rather than every area that uses that message)

Will be extremely challenging to work with this repo on hardware until we have onboard internet while maintaining local network connection.

This should help us more quickly test easy gaits.

Clark controller would give us simple controller to use to test contact detection, state estimation, etc. before development of MPC controller is complete

Populate linear and angular velocity from filtered diff of mocap angular data

Refine open loop controller with better end effector trajectories and gains for better open loop walking.

• Add contact force plugin back in (move from SDF to URDF)
• Add force plugin (gives capability of applying external wrench via ROS)
• Tie in to clark trot controller

The gazebo simulator should expose a topic over the ROS network allowing us to apply a wrench to the robot's body for a specific duration (i.e. 0.5 s, 2s). I believe there is a gazebo plugin called "force" that might do something similar, but there is very little documentation on it.

Bonus points if we can change the location the wrench is applied to and double bonus points if we can apply wrenches to any link in the URDF instead of just the body.

Currently most of the nodes just start running and publishing immediately even if the topics they are subscribed to haven't yet been populated. This can be an issue for the planners, as they require populated data to run smoothly. We need a way to ensure things start up in the proper order to avoid finicky errors. I expect this will save a lot of time once we start running things on the robot.

MBLink ships with SpiritSDK, but we have no need for the whole SDK. Remove the excess stuff and just add the relevant libraries and headers.

Add some filters to process the terrain map for computing foothold scores, similar to this one with search or this one with CNNs.

There should still be separate topics (/state/estimate, /state/ground_truth, /state/trajectory) which are all of this type.

Take in grfs message and another custom message holding swing leg trajectories, output a MotorCommandArray message

Add ROS subscriber to read_write_host from SpiritSDK, embed in spirit-software

The Doxygen pulls the wrong readme for the repo front page, we should have it point to a more helpful page (and populate that page).

Use .stl files in SDF instead of using rectangles. Purely for aesthetics, don't do collision checking with complex polygons.

Requested features are (in descending priority):

1. Linear
2. Bilinear
3. Cubic

Lightweight and fast are desired attributes. Should be implemented as a class within spirit-utils.

Subscribe to and publish the correct topics

These can be empty although the publishers/subscribers should be set up correctly, along with the proper message types. The goal is to create a complete rqt_graph. Remaining components are as follows. Note that the naming conventions are not set in stone yet and should be discussed, and any missing nodes/topics should be added.

Nodes

• ekf_estimator
• mpc_controller
• mocap_interface
• spirit_logger
• contact_detection
• visualizer

Topics:

• ekf_estimator/robot_state
• mocap_interface/robot_state
• contact_mode
• grf_plan

See equation (33) here.

Should only be a few lines of code but would be helpful to test the online visualization which I might do today.

Would be nice if running the setup script would automatically either clone this package and edit the yaml file accordingly, or if we had a fork in this repo with the proper config that we could use.

Travis should identify and install all rosdep defined dependencies in the build process

In it's current setup, we can run the Gazebo sim in either position control or torque control mode. The output of many of our controllers (and the input of the actual hardware) is a combination of the two; desired joint positions and velocities as well as feedforward torques. It would be nice to replicate this interface in our simulator as well.

Gazebo should expose a single topic called /spirit/gazebo/control_inputs of type MotorControlInput (defined in spirit_msgs). This will contain desired joint torques, joint positions, joint velocities as well as gains kp and kd for each joint. The controller should interpret these interpret these inputs according to the control law below and apply the resultant torques to each joint respectively.

Some good references on how effort_controllers work can be found here. What we want is effectively a new effort_controller called joint_feedforward_position_controller. Look over the other controllers in the referenced folder to see how they work with gazebo.

Contact detection plugin reports toe_contacts one by one as they come in instead of just querying each toe contact sensor at some frequency. It also appears that the plugin does not discriminate between contacts with the environment and contacts with itself or another link on the robot.

Implement some form of sensor reading cache in the contact_plugin class that listens for ~3-5 ms and then spits out the registered contacts in that time frame.

Travis build server should verify that the build process works on the arm64 architecture because the TX2 is based on that