Work: Robot Driver, Inverse Kinematics, and general Arm movement
Group members: Raghav and Alex
We did pair programming on every module. Here is the core setup currently:
Core Setup:
We have two primary python modules that the main robot driver module utilizes. The first (InverseKinematics.py) uses Inverse Kinematics to ultimately get the robot's center wrist to a certain target point (in the base_link frame). The second (read-write api) makes it really easy to specify custom movements for joints over time. We're currently setting up the main method that alternates between using the two: using the IK to move the limbs to a certain point, and then the read-write api to move the limbs in a custom way from there.
InverseKinematics.py:
We initially followed the stretch tutorial for Inverse Kinematics on the hello-robot GitHub repository. After lots of error debugging, and some minor tweaks not mentioned on the documentation (ex. adding imu_mobile_base to the links to remove when generating a chain of limbs from the tree of limbs), we got inverse kinematics to work. We tested using a target point that follows a sine wave relative to the base_link frame, and behavior was as expected.
*We got it to work using the tutorial's robot api. However we are currently replacing the robot api with our read-write api (see below) to be compatible with other ros2 modules and functionality. The robot.move_to and robot.translate_by methods cannot be used if we want to run our read-write api for both non inverse kinematics movements and inverse kinematics movements.
ReadWriteApi.py:
This module handles arm movement. We created it to simplify 1) moving multiple joints to various positions over time, 2) getting any joint's current position. It exposes a write and read function respectively. The write function just requires "data" (and no code) to be passed in! It setups the required data structures and joint trajectory to execute using for loops and some abstraction, so the user just needs to focus on specifying how they want the joint positions to be set over time! See inputs to write function below:
After experimenting with the write functionality, we figured out the core driver works best on position mode instead of trajectory mode. Joint movements were sharper and more precise when changing their specified position values at different times.
Main (robot driver)
- setups the robot, initializes the above two modules, and handles the logic for when to alternate between IK and the read-write api. In the future, when we receive data from the computer vision team, this is where we pass in the target_point for Inverse Kinematics every 0.2 seconds.
Other functionality complete:
- a FrameListener.py module that helps converts a position (ex. target point) to a different frame
Currently working on
- replacing the stretch robot api passed into the IK with the read-write api so both can be used simultaneously (compatibility issues with robot api and read-write api which requires ros driver). this will require lots of robot testing to confirm IK is properlty rewritten and still functions correctly (currently been waiting 2 hours for the robot to test some of our newly rewritten code! It's a patience game :D)
- To-do: test stretch robot on physical towel, bowl with liquid, and fixed point for forearm (before computer vision team is ready to integrate their code with ours)
TO-DO: Add pictures of robot doing stuff here
Work: ROS Logic, Contracts, Arm Movement
Group Members: Nelson
My main work has been logistical primarily, partly due to us deciding that navigation is not a core feature of the robot, but I have been assisting with Arm movement in terms of something concrete.
I have been generally working on really understanding the ROS2 architecture and writing the basic contracts and callback methods that allows the various nodes that we need to work together.
I have also been handling various Python-nitty-gritty details (setting up the packages for Python/ROS2 to read).
Not a whole lot of concrete work, but a lot done under the hood.