Gains:
- Ability to set up and solve forward/inverse kinematics and trajectory planning problems with the help of AI
- Ability to produce safe orbit by giving robot joint limits, speed and acceleration constraints as context to the prompt
- Ability to numerically and physically verify the kinematic and trajectory output produced by the AI
Bringing the gripper at the end of a robot arm to a certain point in space, in a certain orientation; It sounds simple, but there are kinematic equations, joint limits, singularities and trajectory planning behind it. Here, the mechatronics engineer uses trigonometry, linear algebra and control theory together. Artificial intelligence is a powerful aid in this process: it can establish forward kinematics equations, suggest solution approaches for inverse kinematics, parameterize a trajectory according to velocity/acceleration constraints. However, robotics is one of the areas in mechatronics with the highest physical risk; If an angle sequence generated by the AI is sent to the robot without verification, the arm may hit itself, the environment, or the operator. In this unit we will see how to set up and verify kinematics and trajectory planning with AI.
Forward and Inverse Kinematics
Forward kinematics (FK): Finding the position and orientation of the end-effector if the joint angles are known. There is only one solution, it is direct.
Inverse kinematics (IK): If the desired position of the end function is known, finding the joint angles that will provide this. It usually has more than one solution (like elbow up/down), sometimes it has no solutions (unreachable point), sometimes it has infinite solutions (singularity).
concept
input
output
Number of solutions
Forward kinematics
joint angles
Extreme position/orientation
single
Inverse kinematics
Extreme position/orientation
joint angles
Multiple/none/infinite
For a two-joint planar arm, inverse kinematics can be set up in the AI and verified manually as follows:
import numpy as npdef inverse_kinematik_2r(x, y, L1, L2): """IK for 2-joint planar arm. Returns angles in radians (elbow-down solution).""" r2 = x**2 + y**2 # Accessibility check: is the point in the workspace? if np.sqrt(r2) > (L1 + L2) or np.sqrt(r2) < abs(L1 - L2): raise ValueError("Point is outside the accessible working space") cos_t2 = (r2 - L1**2 - L2**2) / (2 * L1 * L2) cos_t2 = np.clip(cos_t2, -1.0, 1.0) # numericalsecurity t2 = np.arccos(cos_t2) # elbow down t1 = np.arctan2(y, x) - np.arctan2(L2*np.sin(t2), L1 + L2*np.cos(t2)) return np.degrees(t1), np.degrees(t2)# Validation: L1=L2=1, target (1,1) -> expected t2=90 degreesprint(inverse_kinematik_2r(1.0, 1.0, 1.0, 1.0)) # ~ (0.0, 90.0)
The critical lines here are where the AI often skips: reachability check (is the point in the workspace) and `np.clip` (prevents arccos input from going beyond ±1 due to rounding error). Without these two protections, the code will produce NaN or crash at an invalid point.
Tip: When asking for IK resolution, clearly tell the AI to "add accessibility control and limit arccos input to clip". These two lines prevent the silent errors that cause the most headaches in the field.
Joint Limits, Singularity and Multiple Solutions
Each joint of a real robot has an angle range (e.g. -170° to +170°), a speed limit, and an acceleration limit. Even if IK gives a mathematically valid angle, it cannot be used if that angle is outside the physical range of the joint. Additionally, the robot falls into singularity in some configurations: two axes are aligned, one degree of freedom is lost, and joint velocities try to go to infinity for a small tip movement.
That's why HR solution alone is not enough; Every solution must pass an acceptability filter:
def solution_gecerli_mi(acilar_deg, limits_deg): """pains: [t1,t2,...], limits: [(min,max),...]""" for pain, (amin, amax) in zip(acilar_deg, limits_deg): if not (amine <= pain <= amax): return False, f"Joint limit exceeded: {pain:.1f} deg ({amine},{amax}) except" return True, "OK"limits = [(-170, 170), (-120, 120)]print(cozum_valid_mi([0.0, 90.0], limits)) # (True, 'OK')print(cozum_valid_mi([0.0, 150.0], limits)) # (False, 'Joint limit exceeded...')
AI can give the "mathematical" solution of IK; but joint limits and singularity avoidance are specific to your system and must be given as context to the prompt.
Orbit Planning
Getting the robot from point A to point B is not about drawing a straight line between two angles. Sudden speed change creates mechanical shock and vibration. Instead, soft profiles are used: trapezoidal velocity profile (constant acceleration–constant speed–constant deceleration) or S-curve (smoother, where acceleration is also limited). When making the AI generate a trajectory, you must give the target, duration and constraints.
import numpy as npdef trapez_yorunge(q0, q1, v_max, a_max, dt=0.01): """Trapezoidal velocity profile for a single joint. The position array is returned.""" distance = abs(q1 - q0) direction = np.sign(q1 - q0) t_speed = v_max / a_max distance_speed = 0.5 * a_max * t_speed**2 if 2 * distance_speed > distance: # triangular profile (v_max not reachable) t_speed = np.sqrt(distance / a_max) t_constant = 0.0 v_peak = a_max * t_speed else: t_constant = (distance - 2 * distance_speed) / v_max v_peak = v_max T = 2 * t_accelerate + t_constant t = np.arange(0, T, dt) # ... position calculation for each t (based on acceleration/constant/deceleration phases) return t, T, v_peak, duration, vz = trapezoidal_trajectory(0.0, 90.0, v_max=60.0, a_max=120.0)print(f"Total duration: {duration:.3f} s, peak speed: {vz:.1f} deg/s")
The logic check here is this: if the distance is short, the motor will never reach v_max and the profile will turn from trapezoidal to triangular. If the AI misses this condition, the wrong duration will be calculated for short movements. You can verify this by testing the code with a known value (for example, a very short distance).
Weak Prompt / Strong Prompt
WEAK:"Write a trajectory that takes the robot arm from A to B."(No constraint: speed limit? acceleration? joint spacing? Blind output.)STRONG:"Generate a point-to-point trajectory in joint space for a 6-axis robot. The speed limit for each joint is 90 deg/s, the acceleration limit is 180 deg/s^2, the angle range is given in the table. Use a trapezoidal velocity profile, if the distance is short, fall into a triangular profile. The output of each joint is Also write a verification function that checks that it does not exceed the limits. Joint limits: {{table}}"
Verification: From Simulation to Robot
The trajectory generated by the AI is verified in this order before going to the robot:
- Numerical: Are the joint angle, speed and acceleration of each step within limits?
- Collision: Along the trajectory, does the arm collide with itself or the environment (visualize/simulate if possible)?
- Singularity: Does the orbit pass through a singularity region (does the Jacobian determinant approach zero)?
- Slow hardware test: Operate the robot at a low speed (e.g. 10%) and monitor it visually.
- Gradual speed increase: Once everything is verified, the speed increases step by step to the nominal value.
Caution: When starting a robot with a new trajectory for the first time, the speed override should always be low and the E-stop should be available. Even if the AI output is “mathematically correct,” an offset, reverse axis, or cable snag in the physical setup will only be revealed with slow testing.
Mini Case
Automation engineer Ece asks the AI for a trajectory code in joint space for a pick-and-place application. The AI produces a trapezoidal profile, but when Ece tests a short-distance move, she sees that the time is negative: the code did not handle the triangular profile case where v_max cannot be reached. Ece corrects this by telling the prompt "if the distance is short, fall into the triangular profile". It then runs the joint angles given by the AI through its validation function against its own limit table and finds that joint 5 wanted +125° at one point, whereas the limit was +120°. He replans the trajectory and monitors it, this time running the robot at 10% speed. In the first round, he sees that the gripper is getting too close to the table and corrects the Z offset. The AI returned a working outline in minutes; but three separate validations (triangular profile, joint limit, slow test) caught three separate real problems.
Common Mistakes
- Using the IK solution without joint limits and accessibility control.
- Not clipping arccos/arcsin entries but producing NaN in case of rounding error.
- Requesting the orbit without limiting speed/acceleration and creating mechanical shock.
- Ignoring singularity zones and letting joint speeds skyrocket.
- Skipping the trapezoidal-triangular profile transition in a short distance and calculating the wrong time.
- Conducting the first orbital test at full speed and without E-stop access.
In summary
- Forward kinematics has a single solution; inverse kinematics can produce multiple, non-existent or infinite solutions.
- IK solutions are necessarily filtered in terms of joint limits, accessibility and singularity.
- Trajectory planning; It uses soft, limit-compatible profiles such as trapezoidal or S-curve.
- At short distance the profile changes from trapezoidal to triangular; this should be handled in the code.
- AI speeds up math; The limits and physical installation context should enter the prompt.
- The new trajectory is always run for the first time with a low speed ratio and accessible E-stop.
Application task
Select a two- or three-joint arm model (with real or imaginary link lengths and joint limits). Have the AI generate an inverse kinematics function and a trajectory planner with this context. Then: (1) manually verify the IK output with a known target (do you put the angles back and return to the same point as the FK), (2) test that the code captures them by giving at least one inaccessible point and one joint limit exceeding target, (3) check that at a short distance the orbital time turns out to be reasonable. Write down how many validation issues you found in the first version of the code and which layer caught each one.