Add your notes here...

Tutorial to set up Nengo Java integration with SCL..

Open eclipse, start a new project, then follow the images below.

Right-click on scl_nengo_ctrl and go to Build Path Configurations.

Right click on the top level and go to export.

Now you should see this jar file in the nengo/lib/ folder and the control module with its three classes

Now go back to the build path configuration and add all the jar files from nengo/lib/ (including the one you just put there)

Under Referenced Libraries -> nengo-1450.jar -> ca.nengo.ui adjust the run configurations for NengoGraphics.class

Open the nengo file in some text editor and add the new .jar file that you created. (in this case scl_nengo_ctrl.jar)

Now you should be able to run the makenet.py file from the Nengo script console.

Nengo Controller Exploration and Improvement

The Jacobian Network

The majority of the complexity of the operational space control network comes from inverting the mass matrix and from computing the Jacobian. An investigation of the performance of a matrix inverse network for large matrices is left for future work. The focus is first on the Jacobian.

Characterizing the Jacobian

The Jacobian is a m by n matrix relating the joint velocities to cartesian velocities (both translational and rotational). Specifically, the (i,j) entry of the Jacobian indicates dxi / dqj so that dx = J*dq. These functions are highly nonlinear, but very well-behaved, smooth and easily characterized. They are weighted sums and products of sines and cosines. Below is an example of one of the elements of the Jacobian for a PUMA robotic arm:

-0.1501 Cos[t0]-0.4318 Cos[t1] Sin[t0]+0.0203 Cos[t1+t2] Sin[t0]-0.4331 Sin[t0] Sin[t1+t2]-0.102 Cos[t4] Sin[t0] Sin[t1+t2]-0.102 Cos[t0] Cos[t3] Sin[t4]+0.102 Cos[t1+t2] Sin[t0] Sin[t3] Sin[t4],0.4331 Cos[t0] Cos[t1+t2]+0.051 Cos[t0] Cos[t1+t2-t4]+0.051 Cos[t0] Cos[t1+t2+t4]-0.4318 Cos[t0] Sin[t1]+0.0203 Cos[t0] Sin[t1+t2]+0.102 Cos[t0] Sin[t1+t2] Sin[t3] Sin[t4]

The question posed here is whether NEF will perform better using a single, high-dimensional pool of neurons, or breaking the computation down into multiple layers. The motivation for reducing the number of layers is two-fold. One, from a practical standpoint, fewer layers in the network mean a smaller delay between a change in stimulus and the corresponding change in the output torques. This is critical for controlling a physical robotic arm such as Neuroarm or PUMA. Two, biologically, a single pool of neurons dedicated to a particular function (in this case, relating task space velocities to joint space velocities) seems more plausible than a divide-and-conquer method which arbitrarily breaks up the functions into simpler ones. In other words, there are many ways to divide the pool into many layers to simplify each stage, but no strong reasons to prefer one over the other, and there is a single way to perform the computation in one stage.

Network Size

The multi-layered approach implemented by the end of summer 2012 used around 47,000 neurons. To compare performance, the network sizes should be the same. Scaling multi-layered network down is somewhat precarious because there are many places to start the reduction and to do so correctly requires a precise knowledge of the performance bottleneck. So instead, as a first-pass, the single-pool network was scaled up. Below is a link to the results for a single-pool, 10,000 neuron population, sweeping each angle from 0 to pi over 600 milliseconds.

10000 Neuron Jacobian Network Plots

This network is about one fifth of the size of the layered network. However, it is much more computationally intensive to find the decoder weights for a single large pool than it is to find many sets of decoder weights for smaller pools. Creating a pool this size required ng-cerebellum’s computing power.

It appears there is something special about the angle theta0. Throughout the variation of that angle, which is the first 600 milliseconds of simulation, the network performs exceedingly well. However, notice that immediately afterwards, it degrades very quickly. It is likely that this is due to a mistake in the training radius, since after sweeping an angle from 0 to pi, the angle input holds the value of pi while sweep the other angles. After adjusting the radius to accommodate for 5 joint angles, each ranging up to pi, increasing the neuron count to 20,000, and slowing down the rate of change in angle input to pi radians per 1.2 seconds, the pool’s performance actually degraded drastically. Consider that the training volume increased by a factor of (sqrt(5*pi^2))^5 / pi^5 ~ 55, but the neuron population used to represent that volume only doubled.

Small Angle Improvement

One way to improve the performance of the jacobian network, while simultaneously cutting down on pool size is to use a small angle assumption. Rather than encoding the whole range of possible angles, we encode the angular deviation from some reference configuration. A separate pool can remember the Jacobian at the reference configuration, while the other pool computes the deviation. Given a large deviation, the reference Jacobian will have to change as well. For something like a drawing task, this will work quite well since the arm will not swing through large angles and will need rather precise control within a small subsection of the configuration space. The improvement in performance is phenomenal. See plots at the link below. However, this produces another problem which is the choice of reference configuration and learning of the Jacobian at those reference configurations.

4000 Neurons with Small Angle Assumption

In these plots, the radius of the training sphere is 59and the input is randomly generated using “make_fourier_input” with components ranging from 1 Hz to 10 Hz and a rms value capped at 18for each angle.

How effective is the small angle assumption at improving performance? Let us consider the training space in either case. For a n-sphere of radius r, the ‘volume’ or content of the sphere is given here:

http://mathworld.wolfram.com/Hypersphere.html

which for a 5-sphere is approximately 5.26r^5. This means that in this case we have reduced the training volume by a factor of 81, while only reducing the neuron count by a factor of 2.5.

Training on a Cube Instead of a Sphere

While the small angle assumption certainly improves performance immensely, it adds the complexity of determining which reference point to use for the computation, and updating the selection of this reference point if the system strays too far. Alternatively, we could train the network on a 5-cube instead of a 5-sphere. The fit around the relevant joint angles can be much tighter. To ensure that all possible sets of 5 angles between -and can be well-represented, a 5-sphere must have radius 5, however, there will never be a single angle with a magnitude greater than so some of this training space is unnecessary. Training over a cube disrupts the isotropy, but the training volume is reduced by almost an order of magnitude (volume of 5-sphere with radius sqrt(5)*pi versus a 5-cube with side length 2*pi) without sacrificing performance within the robot’s configuration space.

Using a uniform grid of training points over all of the robot’s configuration space requires many more points than used by nengo. Suppose we have a grid with 8 points along each dimension. Already this amounts to 32,768 points. At 10 points we are at 100,000 and by 20 we are over 3 million. Interestingly, by default, Nengo uses 500 training points per dimension and would therefore use only 2500 training points.

Working Towards Friendly Scripts

Ideally, the network generation script should work for any robot model. For seamless integration with SCL, it would be best to use an xml file to specify the details of the network (population sizes for the Jacobian, matrix multiplication networks, and matrix inverse network) and a link to the robot’s config xml file for the robot’s kinematic model. Currently, this jacobian network should work with any size jacobian matrix. Once the performance is verified, I will work towards this integration with SCL-style xml files.

Furthermore, all direct references to the Java backend should be replaced with Python in order to use Nengo’s GPU support.

Input from Sam and Kwabena

There are two factors potentially limiting the performance of the Jacobian network--the pool size and the size of the training set. It would be useful to explore both of these axes and determine which is the bottleneck before seeking improvement.

Preliminary findings--the 4000 neuron network from the plots above work rather well even with only 600 neurons. Plots forthcoming. Also, the data analysis scripts have been improved to store information about each trial in a clean manner.

Systematic Investigation of the Neuron Count - Training Points Space ===

Step 1: Using a fixed radius and fixed number of training points, sweep along the neuron count axis, in 50 neuron increments from 50 to 4000. Save this data and these plots and examine how the root mean square error decreases as a function of neuron count. See script “neuron_count_sweep.py.” For the data shown in the link below, the radius is fixed at and the number of training points is 2500 (Nengo’s default of 500 per dimension).

Neuron Count Sweep at 2500 Training Points

Step 2: Using a fixed neuron count, systematically increasing the number of training points drawn randomly from a uniform sphere of fixed radius.

Step 3: Using a fairly coarse grid, sample the entire space (i.e. combinations of neuron count with number of training points). This will create a nice surface plot of the RMSE as a function of these two variables.

Nengo - SCL Integration, Timing

There are two main issues here. One is that given the relatively large size of a neuron network to implement an interesting controller, we cannot simulate it in real-time. This will make it challenging to control the physical robot. If the robot is also being simulated, however, we can slow down the robot simulation to match the nengo simulation. Must ensure that the physics simulation is also going at this speed, then we'd have data and videos of how the neuro-controller would perform if it were running in real-time (such as on neurogrid)

The second issue is inherent to the fact that this is a neuro-controller. There is a delay as the signal propagates through the layers of the network. In the original implementation from summer 2012, the delay is about 200 milliseconds, but we can reduce the post-synaptic time constant significantly (still within biological plausibility) and the new implementation also cuts out a layer. The propogation delay should be closer to 50 milliseconds this time around.

July 11, 2013

Various TODOs and goals for the next couple of weeks

Specifically for integrating with neuroarm

Create a simple way to specify a subregion of the workspace for a particular task that will be reflected when choosing training points for the network. Also, probably want relative resolutions to be the same, i.e. if we're restricting joint 1 to (-pi/16,pi/16) but joint 2 is free to swing in the range (-pi,pi). If we are centered around a nonzero angle, then that offset will have to be built in to the function.
Joint space controller support
Joint position control with PD controller in Nengo
Collect data on jacobian and mass matrix decoder performance

For nengo robot control in general

Finish wiki for existing classes
Single entry point for running SCL and Nengo
After the work-subspace code is ready, create full working demo folder
Extensions: multiple tasks, GPU capabilities, arbitrary amorphous workspace definition

For PUMA jacobian data in particular

Create surface plots for RMS error over range of neuron counts and eval points at different fixed radii. Full space would be radius = pi, but hard to see changes in performance within reasonable simulation time scales. So try smaller spaces first, use consistent training and testing points across all trials.
Note: more neurons will mean a slower simulation, but more training points means more overhead at the beginning of the trial

Wiki

scl-manips-v2 / people / Kevin