Applying torque control in PyByllet makes object fly away from the secene - bulletphysics

So I grabbed latest code from https://github.com/bulletphysics/pybullet_robots
I modified laikago.py example to the following, I'm only controlling one joint using torque.
Strangely enough poor robot flies away from the scene :)
There are two ways to fix it: either decrease simulation time step (line 10) or change torque value to 60 (line 33).
Any ideas what am I doing wrong?
import pybullet as p
import time
import os
os.chdir(os.path.dirname(os.path.abspath(__file__)))
p.connect(p.GUI)
plane = p.loadURDF("data/plane.urdf")
p.setGravity(0,0,-9.8)
timeStep = 1./300 # HERE!!! changing it to 1./400 fixes the problem
p.setTimeStep(timeStep)
urdfFlags = p.URDF_USE_SELF_COLLISION
quadruped = p.loadURDF("laikago/laikago_toes.urdf",[0,0,.5],[0,0.5,0.5,0], flags = urdfFlags,useFixedBase=False)
#enable collision between lower legs (2,5,8 and 11)
lower_legs = [2,5,8,11]
for l0 in lower_legs:
for l1 in lower_legs:
if (l1>l0):
p.setCollisionFilterPair(quadruped, quadruped, l0, l1, 1)
#set damping
for j in range (p.getNumJoints(quadruped)):
p.changeDynamics(quadruped, j, linearDamping=0, angularDamping=100)
p.setJointMotorControl2(quadruped, j, p.VELOCITY_CONTROL, force=0)
#run the simulation
p.setRealTimeSimulation(0)
for i in range (1000):
p.setJointMotorControl2(quadruped, 13, p.TORQUE_CONTROL, force=62) # HERE!!! changing it to force=60 fixes the problem
p.stepSimulation()
time.sleep(timeStep)

I am a bit late to the party, but maybe you are still in search of an answer. The reason is given here: https://pybullet.org/Bullet/phpBB3/viewtopic.php?t=12644 and a note was added to: https://docs.google.com/document/d/10sXEhzFRSnvFcl3XxNGhnD4N2SedqwdAvK3dsihxVUA/edit#heading=h.jxof6bt5vhut
The reason: "You need to first unlock/disable the default velocity/position motor. [...] Otherwise, your force/torque has to exceed the default motor." (see first link).
To fix do (same link):
pybullet.setJointMotorControl2(objUid, linkIndex, p.VELOCITY_CONTROL, force=0)

Related

Plot on higher time frame. Security, mutable variable, global variable, function problem

I'm trying to plot the same shape from the 15 min onto the Daily as well. This is the code to plot a shape on the 15 min which works fine;
if crossover(s3K,s3D) and s3K<25 and (s4K-s4D<3 and s4K-s4D>-3) and s4K<35//or s4D-s4K>0 and s4D-s4K<1 and s4K<50 and s1K<40
rwCross:=true
plotshape(rwCross, style = shape.arrowup, location = location.belowbar, color=color.yellow, size=size.small)
But to plot it on the daily i've tried;
rwCrossDaily = security(syminfo.tickerid,'D', rwCross)
plotshape(rwCrossDaily, style = shape.arrowup, location = location.belowbar, color=color.yellow, size=size.small)
Which gives me the mutable variable error. So i tried using a function to get around it;
rwCross_func() =>
if crossover(s3K,s3D) and s3K<25 and (s4K-s4D<3 and s4K-s4D>-3) and s4K<35//or s4D-s4K>0 and s4D-s4K<1 and s4K<50 and s1K<40
rwCross:=true
rwCrossDaily = security(syminfo.tickerid,'D', rwCross_func())
But now it tells me I 'Cannot modify global variable 'rwCross' in function.'
Help please!
Best solution and cleanest solution here is to just make a bool out of your condition in its simplest form:
rwCross = crossover(s3K,s3D) and s3K<25 and (s4K-s4D<3 and s4K-s4D>-3) and s4K<35//or s4D-s4K>0 and s4D-s4K<1 and s4K<50 and s1K<40
rwCross will naturally become true without the if. This way we do not need to have anything mutable, although there are more solutions for situations that we must...
Cheers!

Finding shortest path between N sets in a directed unweighted graph

I want to find an algorithm for the following problem:
Given a directed graph G with starting point s and N sets of nodes, I need to find a path that starts in the start node and then goes to at least one node of every set.
Not all of the nodes are in the sets- only some of them.
There are no nodes that are in more than one set.
For example:
starting point: [n1]
First set: [n5,n6,n8,n9]
Seconed set: [n2,n10]
Third set: [n4,n7]
Forth set: [n3]
Other nodes: [m1..m7]
Showing the graph edges:
In this case a shortest path will be:
[n1,m3,m4,m5,n3,m6,n2,m7,n9]
[n1,m1,n7,m5,n3,m6,n2,m7,n9]
This problem is similar to the generalization of the Traveling salesman problem (wikipedia), but in this case, the graph is directional and unweighted. Also, we have a known start point, we have more than just the nodes in the sets and we can walk on the same node more than once.
I tried starting with a lazy fast way of searching for the closest node from the start to all of the nodes in all of the sets with Dijkstra and then removing the set from the calculation and continue searching for the next closest node from all sets from that point.
It is easy to notice that this way doesn't give the shortest path, but the real problem is that sometimes it falls to a dead-end and returns "no path" even when there is a path.
A naive way I can see that can be used is to create a function to calculate for every specific permutation of sets and use an algorithm like the one suggested here for a close but easier problem.
It will take O(|N|! * 2^(the number of all nodes in all the N sets))
Adding the code of the lazy way (sorry for the mess).
from Queue import Queue
from my_utils import RGBtoHex
from igraph import *
from random import choice
class path_info:
def __init__(self, way, length_of_way, satisfied_goal):
self.way = way
self.length_of_way = length_of_way
self.satisfied_goal = satisfied_goal
class graph_actions():
# Goal point has a "start" node and all other goal points are saved in a dictionary
def __init__(self, graph, goal_points):
self.graph = graph
self.goal_points = goal_points
self.best_path = list()
def calculate_best_path(self):
self.best_path = list()
queued_best_path = scatter(self.graph, self.goal_points)
while not queued_best_path.empty():
self.best_path.append(queued_best_path.get())
return self.best_path
def scatter(graph, goal_points):
best_path = Queue()
starting_point = goal_points["start"]
del goal_points["start"]
paths_dict = dict()
return find_best_way(best_path, goal_points, graph, paths_dict, starting_point)
def find_best_way(best_path, goal_points, graph, paths_dict, starting_point):
last = -1
while len(goal_points) > 0:
vertex_color = known_colors[choice(known_colors.keys())]
for vertex in goal_points.keys():
# Find shortest paths from vertex
# Color vertex
graph.vs.find(str(vertex).encode('ascii', 'replace'))["Fill Color"] = RGBtoHex(vertex_color)
# Find shortest path if exist with igraph function
way = graph.get_shortest_paths(starting_point, vertex)
if len(way[0]) != 0:
if (last != -1):
# Taking out the first node that is the end of the last route taken
way[0].pop(0)
paths_dict[vertex] = path_info(way, len(way[0]), goal_points[vertex])
# Find the closest node
stage = min(paths_dict, key=lambda x: paths_dict[x].length_of_way)
# Transfer from list to queue
for step in paths_dict[stage].way[0]:
best_path.put(step)
last = step
# Delete the other nodes with of the same group from the goal list
for key, value in goal_points.items():
if paths_dict.has_key(stage) and value == paths_dict[stage].satisfied_goal:
del goal_points[key]
if key != stage:
del paths_dict[key]
del paths_dict[stage]
# Saving the last node of this route
starting_point = last
graph.save("states_graph_color.graphml", "graphml")
return best_path
Is there a way that is better than the naive? If not, can I use a heuristic way to do this?
I also wonder if igraph has a trick to this in a more clean way.
Even if only the naive way is possible, I'm not sure how to implement it.

Why do I get odd 0,0 point in Octave trisurf

I am trying to draw a surface from a file on disk (shown below). But I get an odd additional point at co-ords (0,0).
The file appears to be in correct shape to me.
I draw the chart from my C# application with a call to Octave .Net. Here is the Octave part of the script:
figure (1,'name','Map');
colormap('hot');
t = dlmread('C:\Map3D.csv');
# idx = find(t(:,4) == 4.0);t2 = t(idx,:);
tx =t(:,1);ty=t(:,2);tz=t(:,3);
tri = delaunay(tx,ty);
handle = trisurf(tri,tx,ty,tz);xlabel('Floor');ylabel('HurdleF');zlabel('Sharpe');
waitfor(handle);
This script is called from my C# app, with the following , very simple, code snippet:
using (var octave = new OctaveContext())
{
octave.Execute(script, int.MaxValue);
}
Can anyone explain if my Octave script is wrong, or the way I have structured the file.
Floor,HurdleF,Sharpe,Model
1.40000000,15.00000000,-0.44,xxx1.40_Hrd_15.00
1.40000000,14.00000000,-0.49,xxx1.40_Hrd_14.00
1.40000000,13.00000000,-0.19,xxx1.40_Hrd_13.00
1.40000000,12.00000000,-0.41,xxx1.40_Hrd_12.00
1.40000000,11.00000000,0.42,xxx1.40_Hrd_11.00
1.40000000,10.00000000,0.17,xxx1.40_Hrd_10.00
1.40000000,9.00000000,0.28,xxx1.40_Hrd_9.00
1.40000000,8.00000000,0.49,xxx1.40_Hrd_8.00
1.40000000,7.00000000,0.45,xxx1.40_Hrd_7.00
1.40000000,6.00000000,0.79,xxx1.40_Hrd_6.00
1.40000000,5.00000000,0.56,xxx1.40_Hrd_5.00
1.40000000,4.00000000,1.76,xxx1.40_Hrd_4.00
1.30000000,15.00000000,-0.46,xxx1.30_Hrd_15.00
1.30000000,14.00000000,-0.55,xxx1.30_Hrd_14.00
1.30000000,13.00000000,-0.24,xxx1.30_Hrd_13.00
1.30000000,12.00000000,0.35,xxx1.30_Hrd_12.00
1.30000000,11.00000000,0.08,xxx1.30_Hrd_11.00
1.30000000,10.00000000,0.63,xxx1.30_Hrd_10.00
1.30000000,9.00000000,0.83,xxx1.30_Hrd_9.00
1.30000000,8.00000000,0.21,xxx1.30_Hrd_8.00
1.30000000,7.00000000,0.55,xxx1.30_Hrd_7.00
1.30000000,6.00000000,0.63,xxx1.30_Hrd_6.00
1.30000000,5.00000000,0.93,xxx1.30_Hrd_5.00
1.30000000,4.00000000,2.50,xxx1.30_Hrd_4.00
1.20000000,15.00000000,-0.40,xxx1.20_Hrd_15.00
1.20000000,14.00000000,-0.69,xxx1.20_Hrd_14.00
1.20000000,13.00000000,0.23,xxx1.20_Hrd_13.00
1.20000000,12.00000000,0.56,xxx1.20_Hrd_12.00
1.20000000,11.00000000,0.22,xxx1.20_Hrd_11.00
1.20000000,10.00000000,0.56,xxx1.20_Hrd_10.00
1.20000000,9.00000000,0.79,xxx1.20_Hrd_9.00
1.20000000,8.00000000,0.20,xxx1.20_Hrd_8.00
1.20000000,7.00000000,1.09,xxx1.20_Hrd_7.00
1.20000000,6.00000000,0.99,xxx1.20_Hrd_6.00
1.20000000,5.00000000,1.66,xxx1.20_Hrd_5.00
1.20000000,4.00000000,2.23,xxx1.20_Hrd_4.00
1.10000000,15.00000000,-0.31,xxx1.10_Hrd_15.00
1.10000000,14.00000000,-0.18,xxx1.10_Hrd_14.00
1.10000000,13.00000000,0.24,xxx1.10_Hrd_13.00
1.10000000,12.00000000,0.70,xxx1.10_Hrd_12.00
1.10000000,11.00000000,0.31,xxx1.10_Hrd_11.00
1.10000000,10.00000000,0.76,xxx1.10_Hrd_10.00
1.10000000,9.00000000,1.24,xxx1.10_Hrd_9.00
1.10000000,8.00000000,0.94,xxx1.10_Hrd_8.00
1.10000000,7.00000000,1.09,xxx1.10_Hrd_7.00
1.10000000,6.00000000,1.53,xxx1.10_Hrd_6.00
1.10000000,5.00000000,2.41,xxx1.10_Hrd_5.00
1.10000000,4.00000000,2.16,xxx1.10_Hrd_4.00
1.00000000,15.00000000,-0.41,xxx1.00_Hrd_15.00
1.00000000,14.00000000,-0.24,xxx1.00_Hrd_14.00
1.00000000,13.00000000,0.33,xxx1.00_Hrd_13.00
1.00000000,12.00000000,0.18,xxx1.00_Hrd_12.00
1.00000000,11.00000000,0.61,xxx1.00_Hrd_11.00
1.00000000,10.00000000,0.96,xxx1.00_Hrd_10.00
1.00000000,9.00000000,1.75,xxx1.00_Hrd_9.00
1.00000000,8.00000000,0.74,xxx1.00_Hrd_8.00
1.00000000,7.00000000,1.63,xxx1.00_Hrd_7.00
1.00000000,6.00000000,2.12,xxx1.00_Hrd_6.00
1.00000000,5.00000000,2.73,xxx1.00_Hrd_5.00
1.00000000,4.00000000,2.03,xxx1.00_Hrd_4.00
0.90000000,15.00000000,-0.42,xxx0.90_Hrd_15.00
0.90000000,14.00000000,-0.37,xxx0.90_Hrd_14.00
0.90000000,13.00000000,0.58,xxx0.90_Hrd_13.00
0.90000000,12.00000000,0.03,xxx0.90_Hrd_12.00
0.90000000,11.00000000,0.68,xxx0.90_Hrd_11.00
0.90000000,10.00000000,0.79,xxx0.90_Hrd_10.00
0.90000000,9.00000000,1.54,xxx0.90_Hrd_9.00
0.90000000,8.00000000,0.82,xxx0.90_Hrd_8.00
0.90000000,7.00000000,1.81,xxx0.90_Hrd_7.00
0.90000000,6.00000000,2.33,xxx0.90_Hrd_6.00
0.90000000,5.00000000,2.99,xxx0.90_Hrd_5.00
0.90000000,4.00000000,1.71,xxx0.90_Hrd_4.00
0.80000000,15.00000000,-0.46,xxx0.80_Hrd_15.00
0.80000000,14.00000000,-0.26,xxx0.80_Hrd_14.00
0.80000000,13.00000000,0.55,xxx0.80_Hrd_13.00
0.80000000,12.00000000,0.07,xxx0.80_Hrd_12.00
0.80000000,11.00000000,0.65,xxx0.80_Hrd_11.00
0.80000000,10.00000000,1.08,xxx0.80_Hrd_10.00
0.80000000,9.00000000,1.27,xxx0.80_Hrd_9.00
0.80000000,8.00000000,1.12,xxx0.80_Hrd_8.00
0.80000000,7.00000000,1.98,xxx0.80_Hrd_7.00
0.80000000,6.00000000,2.62,xxx0.80_Hrd_6.00
0.80000000,5.00000000,3.35,xxx0.80_Hrd_5.00
0.80000000,4.00000000,1.27,xxx0.80_Hrd_4.00
0.70000000,15.00000000,-0.56,xxx0.70_Hrd_15.00
0.70000000,14.00000000,-0.33,xxx0.70_Hrd_14.00
0.70000000,13.00000000,0.24,xxx0.70_Hrd_13.00
0.70000000,12.00000000,-0.22,xxx0.70_Hrd_12.00
0.70000000,11.00000000,0.74,xxx0.70_Hrd_11.00
0.70000000,10.00000000,1.19,xxx0.70_Hrd_10.00
0.70000000,9.00000000,1.24,xxx0.70_Hrd_9.00
0.70000000,8.00000000,1.14,xxx0.70_Hrd_8.00
0.70000000,7.00000000,2.26,xxx0.70_Hrd_7.00
0.70000000,6.00000000,2.70,xxx0.70_Hrd_6.00
0.70000000,5.00000000,3.52,xxx0.70_Hrd_5.00
0.70000000,4.00000000,1.05,xxx0.70_Hrd_4.00
0.60000000,15.00000000,-0.50,xxx0.60_Hrd_15.00
0.60000000,14.00000000,-0.60,xxx0.60_Hrd_14.00
0.60000000,13.00000000,0.11,xxx0.60_Hrd_13.00
0.60000000,12.00000000,-0.16,xxx0.60_Hrd_12.00
0.60000000,11.00000000,0.73,xxx0.60_Hrd_11.00
0.60000000,10.00000000,1.08,xxx0.60_Hrd_10.00
0.60000000,9.00000000,1.31,xxx0.60_Hrd_9.00
0.60000000,8.00000000,1.38,xxx0.60_Hrd_8.00
0.60000000,7.00000000,2.24,xxx0.60_Hrd_7.00
0.60000000,6.00000000,2.89,xxx0.60_Hrd_6.00
0.60000000,5.00000000,3.50,xxx0.60_Hrd_5.00
0.60000000,4.00000000,1.11,xxx0.60_Hrd_4.00
0.50000000,15.00000000,-0.40,xxx0.50_Hrd_15.00
0.50000000,14.00000000,-0.37,xxx0.50_Hrd_14.00
0.50000000,13.00000000,0.13,xxx0.50_Hrd_13.00
0.50000000,12.00000000,-0.11,xxx0.50_Hrd_12.00
0.50000000,11.00000000,0.61,xxx0.50_Hrd_11.00
0.50000000,10.00000000,0.92,xxx0.50_Hrd_10.00
0.50000000,9.00000000,1.41,xxx0.50_Hrd_9.00
0.50000000,8.00000000,1.39,xxx0.50_Hrd_8.00
0.50000000,7.00000000,2.19,xxx0.50_Hrd_7.00
0.50000000,6.00000000,2.80,xxx0.50_Hrd_6.00
0.50000000,5.00000000,3.41,xxx0.50_Hrd_5.00
0.50000000,4.00000000,1.05,xxx0.50_Hrd_4.00
0.40000000,15.00000000,-0.25,xxx0.40_Hrd_15.00
0.40000000,14.00000000,-0.44,xxx0.40_Hrd_14.00
0.40000000,13.00000000,0.02,xxx0.40_Hrd_13.00
0.40000000,12.00000000,0.00,xxx0.40_Hrd_12.00
0.40000000,11.00000000,0.69,xxx0.40_Hrd_11.00
0.40000000,10.00000000,0.67,xxx0.40_Hrd_10.00
0.40000000,9.00000000,1.02,xxx0.40_Hrd_9.00
0.40000000,8.00000000,1.29,xxx0.40_Hrd_8.00
0.40000000,7.00000000,2.17,xxx0.40_Hrd_7.00
0.40000000,6.00000000,2.88,xxx0.40_Hrd_6.00
0.40000000,5.00000000,3.19,xxx0.40_Hrd_5.00
0.40000000,4.00000000,0.98,xxx0.40_Hrd_4.00
0.30000000,15.00000000,-0.02,xxx0.30_Hrd_15.00
0.30000000,14.00000000,-0.36,xxx0.30_Hrd_14.00
0.30000000,13.00000000,-0.26,xxx0.30_Hrd_13.00
0.30000000,12.00000000,-0.11,xxx0.30_Hrd_12.00
0.30000000,11.00000000,0.50,xxx0.30_Hrd_11.00
0.30000000,10.00000000,0.50,xxx0.30_Hrd_10.00
0.30000000,9.00000000,1.01,xxx0.30_Hrd_9.00
0.30000000,8.00000000,1.28,xxx0.30_Hrd_8.00
0.30000000,7.00000000,2.11,xxx0.30_Hrd_7.00
0.30000000,6.00000000,2.89,xxx0.30_Hrd_6.00
0.30000000,5.00000000,3.16,xxx0.30_Hrd_5.00
0.30000000,4.00000000,0.95,xxx0.30_Hrd_4.00
What's happening
dlmread() is reading the file in as numeric data and returning a numeric matrix. It doesn't recognize the text in your header line, so it silently converts that row to all zeros. (IMHO this is a design flaw in dlmread.) Remove the header line.
How to debug this
So, you've got some zeros in your plot that you didn't expect to be there? Check for zeros in your input data:
ixZerosX = find(tx == 0)
ixZerosY = find(ty == 0)
ixZerosZ = find(tz == 0)
The semicolons are omitted intentionally there to get Octave to automatically display the results.
Better yet, since doubles are an approximate type, and the values might be close to but not actually zero, do a "near zero" search:
threshold = 0.1;
ixZerosX = find(abs(tx) < threshold)
ixZerosY = find(abs(ty) < threshold)
ixZerosZ = find(abs(tz) < threshold)

ITK Filter Error: "Inputs do not occupy the same physical space" after affine registration

I'm attempting to perform diffeomorphic demon registration of two MRI images. The processing pipeline has been this so far:
Skull-stripping
Anisotropic Diffusion (smoothing)
Histogram Matching
Affine registration
Diffeomorphic Demons Registration
I didn't come up with the process, just fixing and cleaning up a Slicer software tool several researchers have built. I'm a summer student and quite unfamiliar with domain, however I've started to more less understand what's going on. The problem I've been unable to solve for the past several weeks is this error:
itk::ExceptionObject (0x1231130)
Location: "void itk::ImageToImageFilter<TInputImage, TOutputImage>::VerifyInputInformation() [with TInputImage = itk::Image<itk::Vector<float, 3u>, 3u>; TOutputImage = itk::Image<itk::Vector<float, 3u>, 3u>]"
File: /home/parallels/Desktop/Slicer-SuperBuild/ITKv4/Modules/Core/Common/include/itkImageToImageFilter.hxx
Line: 241
Description: itk::ERROR: DiffeomorphicDemonsRegistrationFilter(0x13870b0): Inputs do not occupy the same physical space!
InputImage Origin: [7.9639916e+01, -1.1042095e+02, -1.0426932e+02], InputImageMovingImage Origin: [-8.8678563e+01, -1.4923204e+02, 1.2193930e+02]
Tolerance: 1.5000000e-05
InputImage Spacing: [1.5000000e+01, 1.5000000e+01, 1.9199951e+01], InputImageMovingImage Spacing: [1.5154560e+01, 1.5108180e+01, 1.9319538e+01]
Tolerance: 1.5000000e-05
InputImage Direction: 1.5926319e-08 1.4070701e-08 -1.0000000e+00
9.9237583e-01 -1.2324859e-01 1.4070700e-08
1.2324859e-01 9.9237583e-01 1.5926320e-08
, InputImageMovingImage Direction: -0.0000000e+00 5.5205551e-10 1.0000000e+00
5.5205551e-10 1.0000000e+00 -5.5205553e-10
-1.0000000e+00 5.5205551e-10 0.0000000e+00
Tolerance: 1.0000000e-06
From what I understand, the diffeomorphic registration relies on the two images being coincident, hence the affine registration step beforehand. For some reason though, the affine transformation doesn't line up the two images properly. As a result, they don't occupy the same physical space. I'm clearly missing something but can't seem to figure out what it is.
The affine registration is performed with this file (I made some edits on my local copy to comply with the Slicer module's way of input/output but they're nearly identical). The transform that was created had the following characteristics:
Optimizer stop condition: RegularStepGradientDescentOptimizerv4: Step too small after 33 iterations. Current step (9.76563e-05) is less than minimum step (0.0001).
Result =
Center X = -1.95155
Center Y = 11.6381
Center Z = 36.5165
Translation X = 1.09423
Translation Y = 0.021133
Translation Z = -0.0154539
Iterations = 34
Metric value = 8974.52
Scale 1 = 1.15384
Scale 2 = 1.08962
Angle (degrees) = -5.6116
The following code was used to save the transform to a file:
// Write the transform to a file
itk::TransformFileWriter::Pointer transformWriter = itk::TransformFileWriter::New();
transformWriter->SetInput( registration->GetOutput()->Get() );
transformWriter->SetFileName( outputMatrix.c_str() );
transformWriter->Update();
And the demon registration is performed with this file (Made a few edits but mostly the same as well). The affine transform is loaded at line 799.
Reading transform from transform input file.
Found: AffineTransform (0x1e0c0b0)
RTTI typeinfo: itk::AffineTransform<double, 3u>
Reference Count: 3
Modified Time: 1322
Debug: Off
Object Name:
Observers:
none
Matrix:
1.01338 0.0887047 0.0223631
-0.11891 1.09423 0.021133
-0.0154539 0.0302253 1.14062
Offset: [-0.256888, -34.7809, -17.895]
Center: [-1.95155, 11.6381, 36.5165]
Translation: [1.56597, -32.6804, -12.3781]
Inverse:
0.977286 -0.0787352 -0.0177019
0.105999 0.905809 -0.0188607
0.0104321 -0.0250698 0.876975
Singular: 0
Edit: Commenting out the following line does not change anything in the resulting output. ie the initial displacement is not being applied at all. Still don't know why.
typedef typename itk::MultiResolutionPDEDeformableRegistration <ImageType, ImageType, DeformationFieldType, PixelType > MultiResRegistrationFilterType;
typename MultiResRegistrationFilterType::Pointer multires = MultiResRegistrationFilterType::New();
// Commenting out this line doesn't change anything
multires->SetArbitraryInitialDisplacementField ( inputDefField );
It looks like the Diffeomorphic Demons Registration code you are using requires that Fixed and Moving images have the same physical space, meaning:
Origin
Spacing
Dimensions
Did you try to resample your moving image to the fixed image space, and then call the Diffeomorphic Demons Registration with this resampled moving image and fixed image?
I didn't know this EZminc code but it looks like it requires both inputs to be in the same space somehow.

Build network with shortcut using torch

I now have a network with 2 inputs X and Y.
X concatenates Y and then pass to network to get result1. And at the same time X will concat result1 as a shortcut.
It's easy if there is only one input.
branch = nn.Sequential()
branch:add(....) --some layers
net = nn.Sequential()
net:add(nn.ConcatTable():add(nn.Identity()):add(branch))
net:add(...)
But when it comes to two inputs I don't actually know how to do it? Besides, nngraph is not allowed.Does any one know how to do it?
You can use the table modules, have a look at this page: https://github.com/torch/nn/blob/master/doc/table.md
net = nn.Sequential()
triple = nn.ParallelTable()
duplicate = nn.ConcatTable()
duplicate:add(nn.Identity())
duplicate:add(nn.Identity())
triple:add(duplicate)
triple:add(nn.Identity())
net:add(triple)
net:add(nn.FlattenTable())
-- at this point the network transforms {X,Y} into {X,X,Y}
separate = nn.ConcatTable()
separate:add(nn.SelectTable(1))
separate:add(nn.NarrowTable(2,2))
net:add(separate)
-- now you get {X,{X,Y}}
parallel_XY = nn.ParallelTable()
parallel_XY:add(nn.Identity()) -- preserves X
parallel_XY:add(...) -- whatever you want to do from {X,Y}
net:add(parallel)
parallel_Xresult = nn.ParallelTable()
parallel_Xresult:add(...) -- whatever you want to do from {X,result}
net:add(parallel_Xresult)
output = net:forward({X,Y})
The idea is to start with {X,Y}, to duplicate X and to do your operations. This is clearly a bit complicated, nngraph is supposed to be here to do that.