I have the same setup as you to in this tutorial, but i cannot get the bot to move for more than .5 seconds per direction. I havent changed any code at all and double checked the wiring.
Also in the code, to a novice, it appears you are using pins 8 and 9 as pin A & B respectively, but in the diagram they are not hooked up.. Could you please explain that to me.
Pins 8 and 9 were for the rotary encoders which I didn't use in the end, although the article talked about them.
It stops after about a second if it doesn't get another message from the remote, so it sounds like the connection might be flaky.
You could change this:
const unsigned long TIME_BEFORE_WE_GIVE_UP = 1000; // ms
Where 1000 mS is 1 second. But you probably need to work out the underlying problem. Do you have an aerial at all? I stuck a short bit of wire in to help with that.
Also for the interrupt 0 assignment, that doesnt seem to be hooked up either,. Sorry I am rather new at this.
To clarify, my rover is going thru the fwd, left, backwards, right sequence but it is only moving for like .25 to .5 a sec before changing to the next direction in the list.
Might I ask what the delay is in there for? It was my understanding the objective of the code was for it to fw/backward for 10 sec and turn for 1.2 sec.
Thank you for your patience with answering my questions.
EDIT** I am assuming that is the delay between direction changes?
By the way, I changed that value to 2 seconds, and it pulses in a direction for about .5 seconds then waits 2 seconds before changing directions to pulse again. I will try to get a vid.
Er, maybe I was wrong. My mind is still seething over the lengthy delays trying to ban spammers on the forum.
This code here:
// check current drain
while (millis () - start < time_to_go)
{
if (analogRead (0) > 325) // > 1.46 amps
break;
}
That makes it stop if the current drain exceeds 1.46 amps. You might want to tweak that a bit. Perhaps your motors are drawing more than mine did. So if you make it higher, it will draw more current before stopping.
I am assuming that is the delay between direction changes?
tigerdorr:
hi, dagu photo.png, could you please tell me why you need power from arduino board icsp?
Those two wires (red and black) are just +5V and Gnd, which were available on the ICSP pins. Since they are pins on both ends it was easy to wire-wrap them.
tigerdorr:
and why don't you use the jumpers of motors on the chassis?
The red and black wire you see going across the board is just for the voltage readout I stuck on the front, so I could see when the LiPo battery was going flat:
The first row (where I have the wires) are from the encoder on the motor. The other row is for connecting to the Arduino (eg. to an interrupt pin). I wasn't using that personally so you could omit them, ignore them, or tape them up somewhere.
I think the circuit just "ors" the two encoder outputs together so you can have a single interrupt pin (labelled INT on the board) which you connect to an interrupt (eg. D2/ D3) and then to see which way it is turning (if you care about that) connect ENC1 and ENC2 to some other pins.
I didn't care about the encoder as I was driving "visually", so I didn't need it to know exactly how much the wheels had turned.
I just got my Rover 5 and had pulled the retaining bracket (metal L-brac with two screws inside the chassis) to pull the appendage out to set the height. I think it was an EE solution to a ME problem Unfortunately, if you have track slippage with the low profile mode, adjusting the height up will make it worse.
I have a composite eye (lots of IR) coming in next week to see how the Dagu demo will work. The DFR Romeo will be interesting in running the R5 Motor/Encoder Board (4motors/4encoders), (2) servos and (6) tactile buttons. I think there might be a 74HC595 chip and a dev board in there.
Thanks to Nick for opening this thread. I look forward to any further developments to this platform.