A research schedule is a best estimate. Any schedule is a best estimate.
Handle it the same way you would a dev schedule: Here is where we expected to be at this point, here's what we've learned, if our original estimate was overoptimistic here is a revised best estimate based on what we have learned.
If management objects, have an estimate ready for what it would take to make you confident you could meet the original target date: more manpower (beware mythical-MSN-month effects), more investment in tools, purchasing something commercially rather than developing it in house, etc. Deciding whether they can afford that investment is their problem, as is deciding whether to accept revised schedule, out to cancel the effort entirely.
Odds of that last are unlikely, though they may reduce the scope. Ideally, this will be in a way that produces something useful by the original date, then adds the rest on a continuing basis which can be published/patented/rolled out as a subsequent version/addition. That's often a better although in any case. Quoting researcher Steve Boies: "Make it work, make it good, make it great." Implicitly: in that order.
If they flat-out refuse to accept your new estimates, which are bbased on the same expertise that cause them to ask you to lead this effort, all you can do is say "well, I'll do my best, but I've told you my current expectations."
Don't panic. Management appreciates estimates that they know how to plan around, even if it isn't what they would have preferred to hear. And they understand that estimating is an imperfect skill that t takes time to learn.
If dealing with someone who really can't be flexible about this, the lesson learned is the one everyone has to learn: when resonating schedules, allow time for the unexpected. After 30 years in my profession I'm still learning how much pad to add.