The inherent issue associated with trying to estimate research is because while you may have clear objectives (vis a vis functionality of the outcome), there is not always a clear target for the actual solution that is the output of the effort. As such, resarch projects have a much higher component of uncertainty as part of their nature.
There are two aspects of TOC and Critical Chain project management that you might want to consider as part of your planning effort. [Hey -- did anyone expect anything else from me by this time? ;-) ]
The first is the development of the project network by focusing on dependencies leading to the objectives. While the actual content of the later tasks is not very well known in an R&D situation, the ability to detail what needs to be learned along the way, in an "in-order-to-X-we-must-have-Y,-Z,-and-A" fashion can shed a considerable amount of light on the order of work.
The second aspect of CC that is useful in an R&D setting is the 2-point estimating that allows the huge amount of uncertainty in such projects to be taken into consideration. Not only is this applicable to estimation of task uncertainty, but "iteration uncertainty" -- how many design-build-test-fix cycles need to be accounted for. The usual situation is if you plan for 2 iterations, you need 4. If you plan for 4, 4 get used in tweaking and polishing, when 2 would have been enough to meet the project needs. . . . a corrolary of Parkinson's Law.
In CC, Project and Feeding Buffers, while primarily sized by taking into consideration the difference between the two task estimates, can also be adjusted to accomodate additional iterations that you might or might not need. In the above case, the body of the schedule network would probably show 2 iterations, while that chain's associated buffer would account for the possibility of needing 2 more.