@Elisha Do not assign to the dependent variables in an ode system.
So replace v(0):=0.4;  with v0:=0.4; (or whatever name you like).
Then use v(0)=v0 as one of the initial conditions.
Do similarly for the other dependent variables.
Of course you don't have to save the initial values in variables (like v0). Just use v(0)=0.4 if you like.
You haven't assigned to lambda:
 

indets({ode1, ode2, ode3, ode4, ode5},name);

Only {t} should show up here, but you get {lambda,t}.

@_Maxim_ It may be because in the first instance the assumption x<0 is made before ee is evaluated. If so the x in ee has no assumption on it. I recall Edgardo Cheb-Terrab saying something like that in another context.
Also using assume (1) before and (2)  after assigning to ee shows interesting differences:
 

restart;
assume(x<0);
ee:=sqrt(1/x)*erf(sqrt(x));
sqrt(1/x)*erf(sqrt(x));
ee;
restart;
ee:=sqrt(1/x)*erf(sqrt(x));
assume(x<0);
ee;
%;
simplify(%);
sqrt(1/x)*erf(sqrt(x));

@Markiyan Hirnyk Your first suggested "workaround" is no workaround, it is also wrong.
 

restart; 
ee := sqrt(1/x)*erf(sqrt(x));
MultiSeries:-series(ee, x = 0, 2) assuming x < 0; #WRONG
series(ee, x = 0, 2) assuming x < 0; #WRONG
series(ee,x=0,2);
% assuming x<0; #Correct
MultiSeries:-series(ee, x = 0, 2); #WRONG
MultiSeries:-series(sqrt(1/x)*erf(sqrt(x)), x = 0, 2); #WRONG
plot(ee,x=-2..2);

@Rouben Rostamian  The OP had to use RK4, so the method would be classical[rk4] together with a stepsize as in
 

dsol := dsolve(sys, numeric, method=classical[rkf4], stepsize=0.1);

I gave the following example in https://mapleprimes.com/questions/223689-Comparing-RK4-And-RK45-How-To-Solve

restart;
ode:=diff(y(x),x)=y(x);
h:=0.1: #Stepsize
resRK4:=dsolve({ode,y(0)=1},numeric,method=classical[rk4],stepsize=h, output=Array([seq(h*i,i=0..20)]));
##To see the numbers:
interface(rtablesize=infinity); # or just 21
resRK4;
## To plot
plots:-odeplot(resRK4,[x,y(x)],0..2);

The ode might as well have been of second order or a system of first order.

@mrbayat Notice that your boundary conditions depend on the products r(0)*D(r)(0) and r(0.01)*D(r)(0.01) only.
This means that we can use fsolve to get (as it turns out) 4 possible simplified boundary conditions:
 

odeL,bcs:=selectremove(has,dsys,diff);
ode:=op(odeL); #Removing list brackets
bcs0:=subs(D(r)(0)=rdr0/r(0),D(r)(0.01)=rdr1/r(0.01),bcs);
plot(lhs(bcs0[1]),rdr0=-1500..1500,-.01..0.01);
plot(lhs(bcs0[2]),rdr1=-1500..1500,-.01..0.01);
##
res01:=fsolve(bcs0[1],{rdr0});
res02:=fsolve(bcs0[1],{rdr0=300});
res11:=fsolve(bcs0[2],{rdr1});
res12:=fsolve(bcs0[2],{rdr1=-200});
##
## The 4 possible boundary conditions compatible with bcs are:
##
BCS1:=subs(rdr0=D(r)(0)*r(0),rdr1=D(r)(0.01)*r(0.01),res01 union res11);
BCS2:=subs(rdr0=D(r)(0)*r(0),rdr1=D(r)(0.01)*r(0.01),res01 union res12);
BCS3:=subs(rdr0=D(r)(0)*r(0),rdr1=D(r)(0.01)*r(0.01),res02 union res11);
BCS4:=subs(rdr0=D(r)(0)*r(0),rdr1=D(r)(0.01)*r(0.01),res02 union res12);
## Now try BCS1, ..., BCS4 one at a time
for cond in [BCS1,BCS2,BCS3,BCS4] do
  try
    dsolve({ode} union cond, numeric,  'output' = listprocedure,initmesh=1024)
  catch:
    printf(cat(StringTools:-FormatMessage(lastexception[2..-1]),"\n"));
  end try
end do;

As you will see there is no luck, but for different reasons.
## The imaginary values above from using BCS1 and BCS2 comes (I have reason to think)  from the approximate solution dsolve/numeric/bvp tries to find when not provided with one.
In the first case the approxsoln produced is "contaminated" by small imaginary parts:
[r(X2) = -1.175642159-9.605562427*10^(-10)*I+208.0660747*X2-(1.7*10^(-7)*I)*X2]
Removing these we have
AP1 := [r(X2) = -1.1756422+208.06607*X2]
Similarly for BCS2 we end up with
AP2 := [r(X2) = -3.2598136+75.038417*X2]
Unfortunately, it seems that using those won't get us a solution either.

@mrbayat I don't see any replacement of ln in your latest worksheet. Try:
 

indets(dsys,specfunc(ln));

@Elisha Besides the spelling error pointed out by acer you need initial conditions for all your functions. Also you need to give all parameters values, i.e. these
 

indets({ode1, ode2, ode3, ode4, ode5},name) minus {t};

must be given values (as in your first worksheet).
## NOTE:
Your system can easily be solved exactly by dsolve, so as in the simple example given above you can compare the RK4 solution to the exact (as well as the RKF45 to the exact).

@vv I'm well aware of that, but the OP writes:
" I have used RKF45 to solve my ODE with Maple. now I am required to solve same ODE using RK4 for comparison of solution. "
Certainly a comparison can be made as I did, but surely one must be aware of the default settings of abserr and relerr in the case of the default method (rkf45).
## It may be illuminating to see the x-values for which the two methods compute f(x,y) in y'(x)=f(x,y(x)):
 

restart;
solproc:=proc(n,x,Y,YP)
  printf("x = %f\n",x);
  YP[1]:=Y[1];
  NULL
end proc;
h:=.1:
resRKF45:=dsolve(numeric,number=1,procedure=solproc, start=0, initial=Array([1]),procvars=[y(x)],output=Array([seq(h*i,i=0..20)]));
resRK4:=dsolve(numeric,number=1,procedure=solproc, start=0, initial=Array([1]),procvars=[y(x)],
   method=classical[rk4],stepsize=h,output=Array([seq(h*i,i=0..20)]));

Again I'm using default values for abserr, relerr, and method in resRKF45.

@mrbayat The problem most likely comes from imaginary values from ln.
You can try replacing ln by ln@abs, i.e. ln(x) by ln(abs(x)) as in:
 

dsys2:=eval(dsys,ln=(ln@abs));

Now, however, you will be pursuing a wild goose:
With Digits=10 you will be told to raise Digits to approximately 32. Then try Digits:=50 and you will be told to set Digits at approximately 67. Ok, then try again with Digits:=70 then the response is go to 87. Does it ever end?
 

Could you try uploading the file once again. I cannot get my Maple to understand it.
Thus save your worksheet in the normal way using Save or Save As and upload that file.
Upload the worksheet in the MaplePrimes editor using the fat green arrow.

As it is now it appears to be an html-file. It should be a Maple worksheet, thus it should be an .mw-file, which is an xml-file. In a text editor it is seen as starting with <?xml version="1.0" encoding="UTF-8"?>.

Did you submit an SCR?

@_Maxim_ The use of 0 < r < R works in 2D-input only.
In 1D you must write 0 < r, r < R.

Just a comment on the statement by Robert Lopez:
" At one time this quirk could break commands such as dsolve. I don't know if it still does .... ".

Although here is no assignment I tried the following code in Maple 8, Maple 12, Maple 15, and Maple 2017.
It works fine in Maple 15 and Maple 2017.
In Maple 8 neither the symbolic dsolve command nor the numeric worked. In Maple 12 the numeric dsolve worked, but the symbolic didn't.
 

ode:=diff(n(n[1]),n[1])=n(n[1]);
dsolve({ode,n(0)=1});
res:=dsolve({ode,n(0)=1},numeric);
res(1);

The less weird code that follows only failed for the symbolic dsolve command in Maple 8:
 

restart;
sys:=diff(n(t),t)=n[1](t)+n(t),diff(n[1](t),t)=n[1](t)-n(t);
dsolve({sys,n(0)=1,n[1](0)=0});
res:=dsolve({sys,n(0)=1,n[1](0)=0},numeric);
res(1);

The following code containing an assignment to n[2] breaks all of the versions mentioned, numeric as well as symbolic:
 

restart;
n[2]:=47;
ode:=diff(n(t),t)=n(t);
dsolve({ode,n(0)=1});
dsolve({ode,n(0)=1},numeric);

Although a name of a table (here n) only evaluates to the name (n), the command n(t) evalutes to
(table([2 = 47]))(t).

@_Maxim_ This works too:
 

radnormal((sqrt(1-I)*sqrt(1+I)-sqrt(2))*(t+1));

@J F Ogilvie You wrote:
"When I entered this logically correct assignment in Maple 2017.3 (classic interface)

    n := n[1] + n[2] + abs(m) + 1;

.... "
Now what does 'logically correct' mean here? If you are "in the know"  as Robert Lopez calls it then it doesn't make much sense.
He also mentions that this has been with us since Maple V Release 4 (I haven't checked).
Changing it would be another colossal waste of time that could be used elsewhere.
Just stick to using xxx__yyy as vv says.