Pps with modulations dev

[alecive]

• [x]  File: modules/visuoTactileRF/vtRFThread.cpp:L11-19
• <img border=0 src='https://avatars.githubusercontent.com/u/4378663?v=3' height=16 width=16'> Is it really needed to hard code a macro for the number of torso and arm joints? Torso joints are already read from the encoder and stored in the jntsT variable. For the arm, you cannot read it from the encoders, but you can have a similar interface, i.e. a jntsAL variable that you initialize to 7 as a member of the class, instead of a #define. :)
• <img border=0 src='https://avatars.githubusercontent.com/u/6461061?v=3' height=16 width=16'> Matter of philosophy - macros make it IMHO more transparent.
• <img border=0 src='https://avatars.githubusercontent.com/u/4378663?v=3' height=16 width=16'> I know that, but since everything else is handled with another philosophy, it's better to stick to the existing one :)
• <img border=0 src='https://avatars.githubusercontent.com/u/6461061?v=3' height=16 width=16'> I prefer having subVector(0,NR_ARM_JOINTS -1) over subVector(0,6). If you object against macros, it can be made a variable with the same name (UPPER_CASE) and initialized in init(). It's slightly more work, but is the same. What is the problem with macro?
• <img border=0 src='https://avatars.githubusercontent.com/u/4378663?v=3' height=16 width=16'> The problem is that the other code uses jntsT jntsR, etc, so I would stick with that , i.e. with a variable (called, to be consistent, jntsAR jntsAL), initialized in the init as you said (this is what I suggested in the beginning). jntsT is already initialized and used, so you can use that for the torso.
• <img border=0 src='https://avatars.githubusercontent.com/u/6461061?v=3' height=16 width=16'> Ok, no problem.
• Torso joints solved by this commit: 0fe466a4bef54ef7af3dfdcefaa0dbd3eda512dd
• (Sorry about this commit: 0fe466a4bef54ef7af3dfdcefaa0dbd3eda512dd - I forgot to pull first, then rebase somehow did not work out and I had to merge manually with your commit with the formatting edits)
• Arm joints solved by this commit 67c7c6f444a068705746f8c50b375c0a79f668c9
• [ ]  File: modules/visuoTactileRF/vtRFThread.cpp:L1099-1106
• <img border=0 src='https://avatars.githubusercontent.com/u/4378663?v=3' height=16 width=16'> At this point, it probably make sense to update also the eyeWrappers into your new method. What do you think? I'm talking about lines 1102:1115 and line 1121
• <img border=0 src='https://avatars.githubusercontent.com/u/6461061?v=3' height=16 width=16'> It seems so - this one is also called repeatedly.
• <img border=0 src='https://avatars.githubusercontent.com/u/4378663?v=3' height=16 width=16'> Or, we can decide to remove (or disable) it altogether since we are not using it anymore.
• <img border=0 src='https://avatars.githubusercontent.com/u/6461061?v=3' height=16 width=16'> Hmm, I'm not using it most of the time, but can be useful. I can add it to the updateChains(). It could be eventually made optional - such that this is computed only when someone is interested to look.
• <img border=0 src='https://avatars.githubusercontent.com/u/4378663?v=3' height=16 width=16'> :+1:
• <img border=0 src='https://avatars.githubusercontent.com/u/6461061?v=3' height=16 width=16'> Ok, addressed by this commit: 8a067ce583f2ad65db02468d4d59ba6d340a64c1 Just need to test now.
• [ ]  General Comment
• <img border=0 src='https://avatars.githubusercontent.com/u/6461061?v=3' height=16 width=16'> Just tested everything - torso joints are taken into account now for remapping to taxel frames. Projections of taxel positions to camera frames are still operational too.
• <img border=0 src='https://avatars.githubusercontent.com/u/4378663?v=3' height=16 width=16'> Good!

  

[matejhof]

Just tested everything - torso joints are taken into account now for remapping to taxel frames. Projections of taxel positions to camera frames are still operational too.

[alecive]

Good!