image-x-institute / 6-dof-robotic-motion-phantom Goto Github PK

I encountered an issue where there was a delay between the expected and actual trace as displayed on the screen.
It didn't occur every run but when it occurred it was noticeable and appeared to be real.
The image below shows this (dotted line = expected, solid line = actual).

Feature request:

It would be great to have a code which takes a pure motion trace measured by a third party measurement system (e.g. KV or surface imaging) and automatically finds the origin of motion.

Can you set a minimum amount of rotation that can be displayed?
Currently, the plot will show down to E-18 degrees which is unnecessary. Displaying down to 1/3600th (seconds) would be sufficient for most applications.

Due to general feedback, the following improvements to the Realtime plots would be ideal to achieve:

1. Reduce the x-axis scaling for the plot in order to make the plot less busy, allowing for space to add a new plot in the same chart. Currently, the x-axis (time) has the range from 0 seconds to the max length of the trace.
2. Implement the translation plots of the 1D robot on the same graph as the 6DOF robot.
3. While reducing the x-axis scaling for the translational plot, implement auto scrolling so that the whole trace file is able to be viewed from beginning to end. the scale for the x axis should have a range of 10-20 seconds max.
4. Allow to toggle between the 6DOF trace, 1D trace or both traces

Allow the user to select verbose logging in the application.
When verbose logging is active, any and all changes to the application should be recorded including payload, loaded file, home position, etc.

If the application isn't in full screen or is being displayed on a different sized screen not all the UI elements are visible.
Add scroll bars to the display if any elements are not displayed.

Record the home position in the log in both application and robot co-ordinate systems.

Allow the user to load a home position (not just set it).
This would be useful in case the application crashes when the robot isn't in the home position.

Traces could be longer e.g. 20 min. But only show the trace that is happening at the present, e.g., 0 s -100 s.

Usually the trace is fed to the software using an input file. So the program at the moment requires a continuous trace.
Add a section in the code to move the robot from one particular point to another.

This should present an error rather than crash the program.

It was sometimes hard to tell whether the UI had registered a button click.
It would be useful for button presses to be highly noticeable or indicated by a change in the UI.
For example clicking home could update the Current position to be all zeros (assuming the robot is actually in the home position).

Warn users that the application co-ordinate system and robot co-ordinate systems are not the same.
In the application settings screen, provide users with a visual demonstration of the co-ordinate system used by the application.

The purpose of this would be to report actual vs expected position of the robot.

a) The location where the achieved robot positions can be found should be included in the help file.
b) I have noted that the application can report robot position with variable frequency, is this a function of the input trace or something else. I have included 2 examples recorded with the same setup only a day apart, one with high recording frequency and one with low.

MotionData_210124-0352_Typical.txt
MotionData_200124-0705_HiFreq.txt

Currently, the application freezes while loading or starting long traces.
There is no update to the UI during this time and it can be in this state for up to 10 minutes depending on the type of trace.

Rather than it crashing, it should present an error and prompt the user to load a compatible file.

Instead of having to restart the trace from the beginning, would it be possible to allow the motion to be paused and then continued instead of forcing a restart?

When I loaded the attached trace to the application and pressed 'play' approximately 170-180 seconds into the trace the robot jumped in all directions (by 3-8 mm) then reported an error and crashed.

Prostate_continuous drift_10Hz.txt

There were times when errors would show up on the robot console but weren't reported in the application.

Either set the sample frequency automatically according to the loaded file.
And/or
Resample all loaded files to 5 Hz

Investigate why 10 Hz files don't load and run efficiently.

The application appears to have a low update frequency of the actual achieved positions and current position.
We found that it was updating the display less frequently than we would like and at time the only way to tell the robot was still moving was to look at the cameras.
This may be related to #8

Allow the user to change the trace without playing it.
For example if the user loads the incorrect trace or changes their mind and doesn't want to click play before loading the new trace.

The origin of motion (z coordinate) needs to be reversed, i.e., when the rotation centroid is calculated w.r.t. the default origin of motion of the TCP, the z coordinate needs to be flipped (as opposed to IEC convention). Please see the updated documentation 'Getting Started' guide. This issue will be fixed in the next release. For the time being, follow the updated documentation.

This won't affect any translational motion, however, will affect rotation around z axis.

The application defaults to a 0 kg payload.
This could be dangerous if the user forgets to update this value before starting motion, particularly with higher capacity robots.

Can the application report on how accurately it achieved the current trace?
Using the expected and the actual could it give an RMS error, along with maximum and minimum error or distribution of errors?

Feature request:

It would be useful if the output motion file from the robot + 1D platform (calculated from the voltages) had an associated uncertainty measurement - this could be calculated from experiments using the platform with various traces (which may need to be repeated a couple of times to see how reproducible the motion is).

The optical feedback plot in the software does not match the input motion traces.

When loading a longer trace (500 seconds +), the 6DOF robot takes a few seconds before it starts playing the trace while the 1D motion platform starts right away. Need to implement a way to make sure both platforms start moving at the same time.

Add help screen, either to directly open the documentation and/or with a brief description of each item in the screen.

As a french Windows set up on a personnal laptop , the code could not load the "settings.txt" file because of the French synthax for decimal numbers (it was ignoring the decimal dots "." as the French version use "," for decimal places).

When loading an extended trace, can only a reduced portion be shown, e.g., the last 30 seconds and the next 180 seconds?
This would allow better visualisation of what has been and what is coming up.

Need to implement a fix that requires the 'Home' button to be pressed once for the Arduino to go to home position.

For heavier and larger payloads, the location of centre of mass (CoM) of the payload is important for the accuracy of the robot.
Allow users to either import a CoM from the robot console or to set the centre of mass in the application settings.

The UR16 motion was jerky when run from the application.