Building brains
Associate professor Pål Kvello started this research project in order to give students a hands-on approach to learning about the brain, and more specifically, it's main building block, the neuron. The idea is to create a model of a neuron, that can send and receive signals from other neurons. With many neurons, one could then reproduce the behaviour of simple networks found in real biological brains.
Pål Kvello holding a network of neurons
Starting point for our part of the project
Version 2 (left) and version 3 (right)
This project has been developed by students, all the way from scratch, and the process has taken four years. My partner, Inge Eide Johnsen, and I joined the project on its fourth and latest generation. The neuron looked and functioned much the same way that it does now, but it had cumbersome plugs, and was therefore very annoying to work with. Our task was to solve this issue.
The solutions was clear: Magnetic plugs. But the current version used three lines: ground, power and data, and we couldn't find nice magnetic plugs that supported 3 lines. So our task became to merge the power and data line, so that we only used two lines. We initially had four ideas of how to solve the problem: Use battery, 1-Wire, a custom 1-Wire like solution or a variable voltage supply. Due to complications, we abandoned two of the ideas, went ahead with the variable voltage supply, but later had to abandon that idea too, and ended up using a battery solution.
Interesting problems
We ran into many problems, but one problem we struggled with was that we needed to receive signals from five dendrites (D1-D5, see image), and keep the signal isolated so that we can receive multiple signals at the same time. We also need to be able to pass on current from a charger through all the dendrites and the axon (AX1). We tried using diodes, but realized we would have a relatively large voltage drop over each diode. So when neurons are connected in larger networks, the total voltage drop would be significant. Instead we used transistors that we could control with the microcontroller.
On the programming side, there were obviously lots of problems as well, but mostly minor bugs.
We did not use an interrupt based system, and because we had no experience implementing sleep modes, the neurons are very power hungry.
We definitely could have made our system interrupt based if we knew how, but finding the right combination of functions and settings
proved difficult.
One of the more interesting parts of the code is the debugging system. We created a set of functions that could print various variables that we could pick up with python
via a COM. We could then plot variables together or seperate in four different plots, and easily get a good understanding of what was going on in the code in real time.
Spending some time making the debugger turned out to be a good decision, and definitely ended up saving us time in the long run.
One of the things that I am taking away from this project, is the value of debugging preparation. In the beginning, we thought that this would be a relatively simple, straight forward problem,
and therefore, always bought PCBs to test out the various schematics. If we had invested the extra initial cost and time it would have taken to properly create the entire circuit
on breadboard instead of PCB, we would have saved ourselves a lot of trouble.
Always assume that there will be problems and make it as easy as possible to find and fix the problems that come up.
Here are some photos taken for the Department of Teacher Education by Elin Iversen/NTNU
