Home Questions How to implement a continuously expanding target ?

How to implement a continuously expanding target ?

DWQA QuestionsCategory: Custom Task DevelopmentHow to implement a continuously expanding target ?
Antoine De Comite asked 3 years ago
Hello, I would like to implement a rectangular target whose width could continuously change (increasing or decreasing at constant speed) during trial on KINARM End-Point. Is it possible to do it without having to implement all the intermediate targets in the target table? Is there a way to use the speed as a task parameter and to add some lines of code inside HandInTarget and ShowTarget so that the increase/decrease in width is directly implemented there?
3 Answers
Duncan McLean Staff answered 3 years ago
Hello Antoine, The short answer is that yes, this is all possible. To do this, you will need to manipulate VCodes, the data output from a Show Target block that tells Dexterit-E what you want displayed on the screen. Section 10.7 of the Task Programming Guide has all of the detail on VCodes. To make the VCode grow and shrink I would suggest:
  • Create a base VCode using a Show Target block.
  • Pass the VCode to an embedded MATLAB function
  • In your TP table create a column that is a "growth factor"
  • In Stateflow, create a new output variable that is the Size Change
    • Reset the size change to 0 at the start of a trial
    • When you need the size to change create a State block and use a "during" clause
    • In the during clause put something like Size change = Size change + growth factor
    • Anything in the during clause is executed at 1 kHz.
  • Send the Size change variable to the embedded MATLAB block
    • Assuming a rectangle, update the size using:
    • VCode(10) = VCode(10) + size change % width
    • VCode(11) = VCode(11) + size change % height
In terms of the HandInTarget, I think you could handle it within the same embedded MATLAB block. While it is possible to manipulate the existing HandInTarget, doing your own calculation is likely easier. 
  • Get the current hand position from the KINdata_bus block and pass into the above embedded MATLAB
  • HandX = HandX - VCode (3) % X position of the target
  • HandY = HandY - VCode(4) % Y position of the target
  • handInTarget = abs(HandX) < VCode(10) && abs(HandY) < VCode(10)
  • The above code checks if the hand is within rectangle's bounds
  • When sending the handInTarget variable back to Stateflow it is likely you will need a Memory block to avoid circularity
Assuming your task is meant to run on either hand, a convenient way to get the hand position from the correct robot is:
  • Use the Bus Selector to pull out (in order) a2_hand_position, active_arm, a1_hand_position
  • Pass those 3 inputs in order into a Switch block
  • Set the switch condition to ">1"
The above technique will pass the arm 2 position (left arm) when the active arm is 2, otherwise the arm 1 (right arm) position is passed. Please let me know if I can help any further. Duncan
Duncan McLean Staff answered 3 years ago
Hi Antoine, Please send your model to support@kinarm.com and I'll look into the build error. In answer to your other questions:
  • Yes, I'd just use one embedded MATLAB block to grow the target and for the HandInTarget code
  • Goto and From is a great way to declutter a model - so yes, great idea!
  • As long as the only target you care about looking at is the growing target then yes you could replace the input. 
  • The unit delay block will work perfectly. I don't know why there is also a memory block, it's just the one I'm in the habit of using.
All the best, Duncan
Antoine De Comite answered 3 years ago
Hello Duncan,   Thanks for the detailed answer! It helped me a lot.
I have implemented the first part that consisted in changing the VCODES with growth factor and I obtained an error that says that the slx could not be built because "The make command returned an error of 2". I verified the simulation parameters of Simulink and everything was fine there and I only obtained this error (that happens after checking all syntaxic erros and variable missmatch) in this task. Do you have any guess of what might be the fix for that?   I also had a few questions regarding the second part (the one about the HandInTarget function).
  • Shall I use the same embedded function as the one I used for the ShowTarget block?
  • Would you recommend to use GoTo and From operations from Simulink to communicate variables from HandInTarget to ShowTarget?
  • Can I just replace the entry of the HandInTarget classical output by the boolean expression you gave me?
  • Is the memory block that I need to avoid circularity similar to a unit delay used to avoid algebraic loop?
Best regards, Antoine