Home Questions Modifying Trajectory System for Position Controller

Modifying Trajectory System for Position Controller

DWQA Questions › Category: Questions › Modifying Trajectory System for Position Controller
Dusty Fox asked 8 months ago
Hello! I am trying to recreate old active reaches as passive reaches using data from input files. I was looking at the sample for creating a hand trail image on the screen in order to understand how to create and read in the files, and the position controller example to see how to appropriately use the position controller/loads for the Kinarm.I removed the feedforward and reduced the maximum force to 10 N, and instead of calculating virt_pos from the trajectory shape and tick count, I am setting it to the x,y coordinates at that timestep. I am able to recreate the movements, but they are fast and jerky, and the controller does not turn off after the movement is finished (but instead waits for the duration). I tried to stop the controller when the current position was equal to the start position (meaning the subject is back to the middle), but that doesn't seem to be working. Any advice here on where to look in the trajectory subsystem would be greatly appreciated! I assume there is a smoother way to achieve this, rather than just replacing the current position (virt_pos) with the data coming in.
1 Answers
Koloman Varady Staff answered 8 months ago
Hello Dusty! If you're reading in recorded data, the time step should be 0.001 . Youshould also make sure to filter the position data in the data file before you create the Input File. I used the filter_double_pass  function in the Kinarm Scripts with a 10 Hz cut off frequency when I did this in a task I made. If you're checking for "when the current position was equal to the start position", you shouldn't make a direct comparison like ==. These are sensor read values that are going to have rounding errors and will probably never be equal - make sure that you're testing "is it close enough, like 1 mm, to the start position" instead. Cheers, Koloman  
Dusty Fox replied 8 months ago

Hi Koloman, thanks for the advice! I currently have it so the time step is 0.001 in the position controller block, and I’m using the double filter with the 10Hz cut off frequency, and its still quite jerky.

I am wondering if the problem is with how I’m using the trajectory subsystem? Is there an easier way to do this besides using the previous subsystem and substituting in the data values instead of the virtual position coordinates? I was considering just feeding the data directly into the position controller, but I was concerned about the forces on the Kinarm / the position force scaling factor not being computed properly. Do you think that is worth trying out? Thank you again for the advice, Dusty

Koloman Varady Staff replied 8 months ago

Sorry for the late response. Hm, tough to say without seeing the code. When I did this, I had a file reading block that worked at 1 kHz and fed that data into the trajectory subsystem with a 1 ms duration for each movement.

I can send you the task – it’s not as user friendly as our official sample tasks but it does show how to read x, y positions from a data file and then move the robot along that trajectory.

Dusty Fox replied 8 months ago

Hey Kolomon, thank you so much! It’s been super helpful and I understand it a bit better now.

I was wondering if you had any advice about re-creating multiple reaches? I added a ‘stop reach’ task button so that the experimenter can manually break between trials, but this can be a bit tricky to get the timing right, and it seems like the filtered data cuts off pieces of the reach if the gap between reaches is too long. I wasn’t sure about how to deal with either a) splitting the reaches into different input files, or b) splitting up the reaches once the input data has been read in. Do you have any advice on this on which approach might be easier?

I really appreciate all the help on this you’ve given us! Thanks, Dusty

Koloman Varady Staff replied 8 months ago

There’s a max of 5 input files – so if you have 5 or fewer reaches, I’d probably do it as separate files. That way you can use enabled subsystems to start/stop reading the files as you want.

Otherwise, when you make the file, you can maybe insert some value that wouldn’t normally occur (like [0,0] for 50 entries) that tell you the reach 1 data has stopped and another reach is going to start if you keep reading.

Cheers,
Koloman