ROS Implementation of AGEVAR MATLAB Code for the Prediction of the Joint Yaw Angle #65
Conversation
- Refactor movement calculations and integrate time-based updates
- Integrate Rotz function into the Agevar node.
- Verify yaw angle updates and motor velocities
There was a problem hiding this comment.
As discussed in the virtual meeting, these are my suggested improvements:
- modify the code to avoid the double indexing of the modules (0,1,... and 0x11, 0x12, ...)
- modify variables so that they have a meaningful name
- with the help of some drawings and the Rviz2 "simulator" identify the correct angles to send to the joints
…management - Modify code to fix inaccurate indexing of modules - Change variable names to improve readability
Simulation.mp4I would like to point out the following difficulties with the code and the simulation: The Problem at the Beginning of the SimulationIn the eighth second of the simulation there is a slight delay in the movement of the robot. This seems to cause the yaw angles of the joints to be updated before the robot actually moves in the simulation. To address this, I made some useful modifications as it was even worse than what you see in the simulation. However, I haven't been able to solve the problem completely yet. Is this likely to create any problems? PD Controller Algorithm IntegrationThe MATLAB code focuses on following a predefined trajectory rather than responding to real-time velocity inputs as in the ROS Python implementation. Therefore, I have integrated a PD (Proportional-Derivative) controller algorithm into the ROS Python code, which was not present in the original MATLAB code. The key reason for this integration is to ensure smoother and more stable transitions in the robot's yaw angle. Would you like to see the PD controller algorithm retained in the ROS Python code, considering it was not used in the original MATLAB code? The updated docs in the Outline is here |
|
About the first topic, I am quite confident that it should not cause issues Moreover in the physical robot usually the robot starts with zero commands applied to the remote controller, and only after that, the values for linear velocity and curvature are changed continuously A test about this could be done, to see how the simulation behaves |
|
From Daniele Latella, resp of Mechanics, about the first topic: "Even though it is not ideal, it should not be a problem. If the force is not excessive there should not be weak points. It should however be tested in practice, since with plastics we cannot be sure" |
|
As previously stated, I would like to see some videos with reasonable commands applied by the remote controller, since sending just one value from the beginning may be the cause of the first problem. This could have been achieved using the trajectory simulation which @Harry0288 is working on. However, it will take some time before we have that, so I would rather suggest you to send a list of values of speed and curvature, using the remote controller topic and a simple publisher, such that the values start from zero and increase gradually, since it could be useful, I would also suggest recording these trajectories in a ROSBAG. After that you can upload the videos to see how the robot is behaving. (ONLY IF YOU HAVE TIME) You should soon receive also a message from @Tizio0o0o0o |
|
In the video the robot starts actuating the joint before it begins moving forward, this might not cause damage in the future (high torque motor, high friction between the robot and the ground, metal joint components) but will now (3d printed joint) so cannot currently be tested (we will do the joint out of metal in the near future). Regarding the PID algorithm, I believe it's a good idea to implement it. |
It actually should not, the left-right movement is considered as a curvature, and is multiplied by the linear velocity (the up-down movement) to obtain an angular velocity, so in this case we should have no movement 1 2 Footnotes |
This pull request brings the AGEVAR algorithm from MATLAB to ROS for predicting the joint yaw angle in our robots. The current implementation may contain bugs.
The short documentation on the main features and modifications of the agevar code is added to the Outline.
The next step might be to send position data in x and y direction (denoted as
eta[m][1]andeta[m][2]) to communication node. But I couldn't find any related topics for position data in the documentations.