Project Title Goes Here

Project team member(s): Allison Sample

Give a one-paragraph description/summary of the project, which includes information like the motivation for the project, the goals of the project, and the resulting implementation and success of the project.

Introduction

Explain the motivation for your project in terms of the educational objectives and why your haptic device is an appropriate approach.

Background

Explain the relevant prior work in the field of haptics and provide references. These will likely be different from the references in your project proposal. Make sure to do a thorough literature search on relevant haptic devices/application.

Methods

Provide a detailed description of your project, such that another student from the class could generally re-create your project/experiment from the report if necessary. (You don't need to document every screw, but the design should be clear.) Add images and videos as needed to support the description. You can refer to downloadable drawings and code in the "Files" section (later). You should divide this section into subsections, which can vary depending on your particular project. Here is an example set of subsections:

Hardware Design and Implementation

System Analysis and Control

Demonstration / Application

Results

Describe the results, which may include qualitative responses from users at the open house.

Future Work

Describe how your system could be tested (e.g., through experiments if you have not already done so), how it can be improved, and how it might be applied.

Acknowledgments

Here you can list any individuals or groups who helped you with your project. (e.g., another student in the class, a course assistant, or an especially helpful PRL TA). Optional, so delete this section if you aren't using it.

Files

Code and drawings should be linked here. You should be able to upload these using the Attach command. If you aren't willing to share these data on a public site, please discuss with the instructor. Also, in this section include a link to a file with a list of major components and their approximate costs.

References

[1] G. Campion, Q. Wang, and V. Hayward, "The Pantograph Mk-II: A Haptic Instrument," in Proc. IEEE/RSJ Int. Conf. Intelligent Robots and Systems (IROS), Edmonton, Canada, Aug. 2005, pp. 723–728.

Appendix: Project Checkpoints

Checkpoint 1

Our goals for Checkpoint 1 were to (i) complete design of the mechanical system (including motor and encoder selection); and (ii) produce a detailed plan of haptic rendering algorithms and controls.

Design of mechanical system

Pantograph design

We designed a four-linkage pantograph inspired by previous ME327 projects that utilize two Hapkits. We decided to fully redesign the sector pulleys and have an overlapping axis for the center rotation of the sectors. The pantograph handle resembles a pen with two axes for rotation that will allow users to get a comfortable grip and simulate a real "drawing" experience. To achieve this, we created a rotating fifth linkage, shown in the image below as the dark orange link. We 3D printed the linkages in PETG using an Ender 3D Printer. Then, to ensure that free space feels truly free, we press-fit solid metal bushings on each of the linkages' ends and used shoulder screws to ensure there was no friction while rotating. The other end of the linkage was intentionally left to be hand-tapped to secure the screw with no additional nuts. The base was designed as well, completing checkpoint 1 and is in the process of being 3D printed with a Bambu printer in PLA filament. The base has spaces to fit five rubber suction cups, and near the motors, it has holes where zipties will secure the motors in place. This part is printed in two parts to reduce the number of supports needed.

Encoders and motor selection

We first planned to use the Maxon RE-max motors because they have 8x more torque than the Mabuchi Hapkit motors at 5V, but the Maxons’ stall current at 5V is higher than the motor driver of the Hapkit board can handle (2A max for the L298P). There were some work arounds that we thought of: 1) limit the voltage applied to 2.10V, and it would still have like 3x more torque than the Hapkit motor, or 2) use Polulu motor drivers to allow for higher voltages and higher torques. For the first solution, there's no safe way to limit current with the Hapkit's motor driver, so we could have run into overheating issues. Additionally, when designing the base for the pantograph, the motors are quite heavy and need to go at the bottom of the base. This complicated the design for the capstans, so we ultimately decided to proceed with the Hapkit motors and the magnetic encoder that comes with the Hapkit board.

Kinematics & Controls

Haptic Rendering Architecture

The block diagram below shows how the three main parts of the system are connected in a closed loop. The user moves the pen tip, the firmware reads the resulting encoder angles and computes a force command, the motors actuate to deliver that command back to the user, and the same pen-tip position is sent over serial to the visual interface.

Please reference the 5-bar linkage below for the variables shown in the block diagram above.

Direct Kinematics

To render force feedback in the correct direction and at the correct location, the firmware needs to know where the pen tip is in 2D Cartesian space at each loop iteration. The only sensors available are the two motor encoders at the base, so we use forward kinematics to map the two measured joint angles (θ₁, θ₅) to the end-effector position P₃ = (x₃, y₃). See figure below for a general 5-bar linkage [1].

Our linkage is a modified five-bar pantograph with the two motors placed at the same x-y location (a₅ = 0), which gives us a wider horizontal workspace than the standard configuration. Following the geometric approach of Campion et al. [1], we treat P₃ as the tip of the triangle P₂P₃P₄, where P₂ and P₄ are the elbows directly driven by the two motors. The derivation proceeds in the following steps:

1. Compute the elbow positions P₂ and P₄ directly from θ₁ and θ₅, since each elbow lies at the end of a link directly connected to the motor.
2. Find the distance between P₂ and Pₕ using the right triangles P₂PₕP₃ and P₄PₕP₃.
3. Compute the altitude ‖P₃ − Pₕ‖ by the Pythagorean theorem.
4. Find the coordinates of the base of the height (Pₕ) from P₃ that's on the segment connecting P₂ and P₄.
5. Step perpendicular to P₂P₄ from Pₕ by that altitude, choosing the sign convention that places P₃ in the "elbow up" half-plane (the configuration the device actually operates in).

The full derivation, including the resulting closed-form expressions for x₃ and y₃ in terms of θ₁ and θ₅, is shown below.

With this forward-kinematics model, given a sensor reading on each loop, the firmware can compute the pen tip's (x, y) position in real time, which is needed for the force-feedback rendering described in the later sections.

Differential Kinematics

Forward kinematics gives us where the pen tip is. To turn the desired force from the force-feedback model into commands the motors can execute, we need the Jacobian. The Jacobian relates joint-angle changes to end-effector displacement, and its transpose maps a Cartesian force at the pen tip to the two motor torques required to produce it: τ = Jᵀ · F_world. This is the step that closes the loop from the force-feedback model back to the actuators.

Because x₃ and y₃ are built up through a chain of intermediate quantities (P₂, P₄, d = ‖P₂ − P₄‖, b = ‖P₂ − Pₕ‖, h = ‖P₃ − Pₕ‖, Pₕ), the partial derivatives ∂x₃/∂θᵢ and ∂y₃/∂θᵢ are computed by the chain rule applied through each of those intermediate quantities in the same order as the forward-kinematics derivation. We follow the chain-rule expressions in Campion et al. [1]; the Jacobian and its set of equations are shown below.

Once the Jacobian is evaluated at the current configuration, the torque required from each motor to render a force F_world = (Fₓ, F_y) at the pen tip would be τ = Jᵀ · F_world. Each Hapkit board then converts its torque to a motor PWM command using the transmission mechanism relation (Tₚ = F · rₕ · rₚ / rₛ) we used in the homework assignments. This completes the sensors-to-actuation loop: encoder reading → forward kinematics → pen-tip position → [force-feedback model] → F_world → Jᵀ → motor torques → PWM → motor command.

Force Feedback Model

For force feedback, we need to convert an image to a series of points that can be used by the microcontroller to check whether the user has penetrated into the shape. Once the penetration depth is known, then force feedback can be calculated with the appropriate direction. The diagram below describes the rendering pipeline from getting from an SVG file through to providing force feedback to the user. Currently, our three demo objects will be the Stanford bunny, a hammer, and a pear.

Now that we have penetration depth and penetration direction, we need to understand how force changes over penetration depth. The graph below shows a gradual slope into the region where the shape is located. Then, a force away from the shape is applied once the user has crossed into the shape. We also define equations for this force where p_T is some penetration depth threshold where we want the user to sit in free space, just outside the shape.

Note: These shapes might feel super discrete. The problem is that for every loop on the microcontroller, we will need to calculate the user's distance from every point in the map. This week, we plan to look into other methods of determining the user's distance from the closest line.

As a final note, we are also considering adding damping or arc-length dependent sinusoidal vibrations to simulate high friction versus low friction surfaces or 'fuzziness' of an object. This will have to be tested with the built pantograph to see if it adds value to object classification.

Graphics

Graphics will be necessary for testing. Black lines from adjacent points in the shape map should be overlaid on the original SVG, and the user's position should be indicated by a small circle (as shown below).

We write a simple UI with database integration on Processing. The flow between these two parts of the system is shown below. We will have an option in the interface to move between shapes. There will be six total shape options, two for each shape: one version will be our controlled group that has no stiffness or textural feedback and the second will have stiffness and textural feedback.

Checkpoint 2

Here you will write a few paragraphs about what you accomplished in the project so far. Include the checkpoint goals and describe which goals were met (and how), which were not (what were the challenges?), and any change of plans for the project based on what you learned. Include images and/or drawings where appropriate.

Example Video: https://www.youtube.com/watch?v=i_aLBql4Ufo