This is just a log for my work in ADAMS Simulation. It helps me keep track of things.
save torq2joint.bin as torq2jointINIT.bin for developing initial conditions and angular velocity output
capability of different initial positions / op was needed for the verification framework
currently it's treated as additional input to the plant
b/c there were strange offset in joint angles, expressions for motion_joint_i (JAD) were listed here for fast references
-VARVAL(drive_joint_1) * 1d + (-4.063d)
-VARVAL(drive_joint_2) * 1d - 156.2680031d
-VARVAL(drive_joint_3) * 1d - (-4.063d)
-VARVAL(drive_joint_4) * 1d + 181.9d
-VARVAL(drive_joint_5) * 1d
-VARVAL(drive_joint_6) * 1d
this didn't work b/c apparently the initial conditions needed to be a constant value rather than a variable
closed without saving, so the torq2joint.bin was still with gravity activated
the control plant was lost but that was OK
deactivated gravity, made all torque input 0, and check the readings
joint_angle_readings = [4.063; 0; -4.063; 0; 0; 0]; % this is degree (unit)
but the numbers generated by the ADAMS block were actually in rad
this coincided with the offset found earlier (see 20180322)
closed the model without saving so it should be fine
would like to see some "step input response" in ADAMS model
but it could actually be done with the Simulink generated by torq2joint.bin
tried driven by torque while keeping the TCP at the origin
it was less successful than that with Simscape model
it could be the direction of the torque or it's just less stable
through derivation of the theoretical model, simple checks were needed to verify the correctness of the result
this could also help me understand the device better, especially with the asymmetry
2 markers were found to represent the direction but haven't dicided how to create the measurement
input: joint torques; output: joint angles; observed with encoders
exported control plant as tqs2jts
coord frame is a biatch...
happened to realize that the rotational axes of joint 2 and 4 were under different conventions
joint 2 was pointing away from the main column while joint 4 was pointing towards
all pointing out was used in the theoretical dynamic model
there was no model built before that was driven by the joints
checked the torque measurements again and they were still wrong
recreated measure_mot_tor_i and drive_joint_i b/c they were deleted in the process
exported control plant as jts2torqs
sanity check with all 0s as joint input and got torque output
equilibrium point: joints = [0; 0; 0; 0; 0; 0]; torques = [-359.3; 217.8; 359.5; 2.40; -0.22; -952.1];
these numbers were verified with both ADAMS and Simulink models
changed the torque measurements to match the new motions (20180323 this actually failed b/c they couldn't be changed)
exported control plant as manipulator_joint_v2
equilibrium points were (probably) needed due to introducing of linmod()
Inputs (active driving motion): motion for each joint (set to zero); Outputs: torque measurements for each motion
this was the pair needed to define each equilibrium point
the first equilibrium point was chosen at the center of the WS, which made sense
but after some initial tryouts, an offset was discovered
basically, the TCP was not at origin when all joints were zeros, indicating offsets in the joints
previously, (see log 20170923) some strange offsets were found in some of the joints
as described previously, this was the file to id joint offsets when TCP was at origin
Inputs (active driving motion): motion of the TCP (set to zero); Outputs: joint angle (encoder) measurements for each joint
discovered a 4.063 degrees offset in joint 1 and 3 which were not compensated previously
went back to test them in the findEqPt.bin and it worked
however, the torque measurements for joint 2 and 4 were not "correct" by the look of it (2 and 200, asymmetrical)
this file was for system verification of the math model we derived and the ADAMS model we built
due to the difficulties in driving the robot in ADAMS with pure joint torques, we formulated the verification as: given a certain trajectory, what's the joint torques
given the fact that ADAMS could only measure torque when there was motion, everything happened in joint space, meaning:
the input was the trajectory given in joint space and the output was the joint torques measured by the motion
deactivated or deleted all the unnecessary I/Os
created measure_mot_tor_i as torque measurement for each joint
created drive_joint_i as angle input for each joint
these two were not included in previous models b/c we seldom considered the robot to be a manipulator
exported control plant as manipulator_joint
haven't been using this for quite a while b/c there were no updates in ADAMS
due to the development of the project, a verification process was needed
and the ADAMS model needed to be tailored to its needs, namely the IOs
there could be several different ADAMS models due to different sets of IOs
new block was put into the Simulink assembly but didn't work
there was a strange offset in joint 1 and 3
changed the setup to run xuan's motion to check the initial pose measurements
discovered there was a new offset for joint 1 and 3
could be b/c the design params changes or my measurements are sensible to params changes
saved nothing and compensated new offsets in Simulink model
Note: check everytime when the design params are changed
Note: the unit for ADAMS model might not be as clear. the angle measurements should be in degrees but they were in rads. I have to check again about torques, Nm or Nmm.
rewrote the IK just to clarify things and have it as a math model
compared this math model with ADAMS model and realized the params for the two are not the same
(no wonder the measurements were off and all)
(how should I explain this to my supervisors, because I'm stupid?)
this was the file to update the params in the ADAMS model to match that in the real device
now, math model, ADAMS model, and the real device should be the same (of the same params setup)
because the TCP was moved due to change of params, I redefined hand motion
with the help from Xuan, the motion now would change with the model
generated 2 Simulink Model from ADAMS
realHDwG: real haptic device with gravity, this would be the main version from now on
realHDwoG: without gravity, feel like it might be useful
assumed everything moved with the model, need to check
there was an offset between the point "TCP" in math model and ADAMS model, choose one (due to universal joint instead of ball joint)
(20170923) kinda solved this by using a F/T transformation formula. have to keep looking
put the new ADAMS block into the Simulink assembly and test
(20170923) it's working now. see related log.
since I successfully rendered a force along z axis, those motor torques should give me a good estimation about directions
checked all the motor torque splines and flipped the direction of motor 1 in simulink
the scope looked better but still there were undesired F/Ts
I also lowered the stiffness of the wall, otherwise, a small error could be magnified like a wrong measurement
NOTE: there could be position errors in all directions
maybe I should start something like this for Simulink Models as well
confirmed the F/T on hand in free space at the origin point with ADAMS model
the Simulink result was the same, meaning the measurements were OK
make sense of the present measurements (may lead to the next item)
double check if the direction of torque on motors were correct
(20170916) flip motor 1. motor 5 might also need to be flipped.
there was no motor model or gear ratio in Simulink right now
I think so far, the model is capable of the whole procedure
This is an attempt to generate the Simulink block for co-simulation
- deactivate all the unrelated motion, measurements, and F/T
- establish measurements on hand w.r.t world frame
the newly generated control related things are Control_Plant_2, this is the whole control plant block with both pathways
I made mistakes in a few I/Os so Control_Plant_2 was abandoned and deleted
regenerated files are whole_plant_bothway
I copied all the newly generated files to the Simulink folder
the old Control_Plant_1 is only the forward (position) pathway
the model would not work after a simple assembly
I realized I never align all the origins in different systems
I went back to test with the forward pathway with forward kinematics (FK)
I created transformation blocks to compensate offsets
NOTE: the model seemed to have a drift in TraY
I tried to make sense of the measurements to make sure they were properly aligned
it actually kinda worked
some of these logs are Simulink related
this is an attempt trying to compensate "everything"
the whole procedure would look like this:
- drive with TCP to obtain joint motion splines
- drive with motors to obtain joint torque splines
- drive with TCP again with compensation from those splines
- take measurements on "hand" when drive with TCP, the second one should be zero
the result looked promising yet confusing
I managed to make F/T on hand (if correct) very close to zero with compensation
but the problem was, it's already close to zero without compensation
this could be correct, since the hand is giving F/T at a far side
like, you are lifting a bar at one side and the rotation point is at the other side
Note: the measurements on hand were w.r.t the world frame right now, it could be wrong
Note: the measurements on hand were w.r.t the hand frame in drive_with_force.bin
given the speed of this "estimation", this could be a strategy to compensate "everything", if we really need one
there is still a possibility that "gravity compensation" is done automatically
repurpose test_motor_torque_sensors.bin to test what should be the right way to measure joint torques
the current question is: what are we really measuring? we have to find a right way and stick to it
changed all torque measurements, from measure joint to measure joint_motion
changed all the measurements to Z component (rotation axis) and w.r.t local coordinate system (joint_axis)
At this point I started to wonder what I did and how that's useful.
zero-gravity test was also done in this file
this gave me some confirmation about sensors' correctness and proof that there were inertial f/t
on the motors the torque with gravity is almost 100 times the torque without
this is not really actuating the whole system with torque only and I doubt that would work
the scenario is to render a force at a fixed point
first, motor-driven, fixed at origin for a while
in the meantime, put a growing force at TCP, point to hand
save motor torque splines for later
next, TCP driven, create measures for those motion
apply those splines and see if we could recreate the force
there are some small drift (noise) but I think it's proved to be basically working
try to see how the motor torque sensors work
try to see what would happen if drive the joints with both motor (position) and torque
we know that when the active part is different (TCP or motors), motor torque measurements differ
set motor active and measure motor torque
save these as splines and apply them while motor active
find a way to measure the F/T on TCP when motor torque is active
(20170914) see drive_with_force.bin, done
initiate this directory
try to have fixed def for angle's direction and bias
the goal was to switch the splines only and the simulation worked correctly
change the measures to function measurements, f(t)
automate this whole process
try to figure out the torque_measuremnets on motors
if possible, does that mean F/T on TCP is also possible?
(20170914) see test_motor_torque_sensors.bin and drive_with_force.bin, done