Using simple serial with arduino

Projects Programming
1

I am trying to communicate using simple serial with the roboclaw motor controller and arduino. I have set the switches to their current positions but still not getting one of my dc motors to operate. it receives the potentiometer value over xbee and this code is what communicates with the dc motor(actuator) channel 2 of the roboclaw where, 128 = full reverse, 192 = stop, 255 = full forward.

I have the 'G' part of the code working for the motor which uses a seperate motor controller. I am having trouble sending data to the roboclaw with the 'B' part, brake, of the code using BMSerial.

2

What's the debug output show?

3

the serial monitor shows the correct pot values for "Brake applied" and "Brake not applied". I do not have the arduinos with me right now but ran them earlier and got the correct outputs over xbee for when the pot changes but nothing from the actuator when it is supposed to be forward/reverse. So it seems to not be sending the 127 or 255 to the roboclaw channel 2.

4

So it seems to not be sending the 127 or 255 to the roboclaw channel 2.

Or 127 and 255 are the wrong values, or the brake instance is connected to the wrong pins, or the motor you have doesn't support braking.

5

tb0508:
.. but ran them earlier and got the correct outputs ...

I'd rather see the debug output.

6

PaulS:

So it seems to not be sending the 127 or 255 to the roboclaw channel 2.

Or 127 and 255 are the wrong values, or the brake instance is connected to the wrong pins, or the motor you have doesn't support braking.

Slide 26 explains the values for simple serial. I am only using 128 or 255 as I need the brake to either apply or not apply fully. I have checked and have the right switches pushed on/off for simple serial and baud rate and have S2(since I have one motor on S1 and the brake on S2, channel 2) to pin 6 as described in top of my code. The receive input of pin5 is not important as the Roboclaw does not transmit anything back.

7

I will post some output soon.

8

Well, now for some reason I get two pot readings when I press the brake pot. I have checked all wiring and everything seems to be fine I have the 5V from my computer into the second arduino. I have all three pots and arduinos with the same ground and have the 5V pin in arduino 2 going into breadboard to supply the three pots and first arduino. When I record the output from the second arduino over xbee I now get two readings....

I have not rechecked the actuator but that was the main reason was I get the values for the Brake but it is not communicating with the roboclaw motor controller to send the 128 or 255 to it to either apply or not apply the actuator. As you can see I get the values across xbee correctly.

This is when I press the brake only.

This is letter: B
<772>
Brake is applied
This is letter: G
<767>
Speed Value Forward: 47
This is letter: B
<742>
Brake is applied
This is letter: G
<707>
Speed Value Forward: 44
This is letter: B
<672>
Brake is applied
This is letter: G
<671>
Speed Value Forward: 41
This is letter: B
<631>
Brake is applied
This is letter: B
<473>
Brake is applied
This is letter: B
<4>
Brake is not applied
This is letter: B
<152>
Brake is not applied
This is letter: G
<159>
Speed Value Forward: 9
This is letter: B
<174>
Brake is not applied
9

Can you clarify what the problem is? What is sending these B and G strings? Are you saying it is sending B twice, or the receiving end things it received B twice?

10

My original problem was communication between the second arduino and the roboclaw. I posted a pdf of the roboclaw and stated that slide 26 explained the 128 and 255 numbers for channel 2. I was wanting to either apply 128 to the actuator(full reverse) or 255(full forward) depending on what the value of the pot (the 'B' part) was. Well, using BMSerial and trying to write to the roboclaw was obviously not working as I could not get it to work.

Now, what I just posted was testing the output . I have 3 pots hooked up to arduino1 that sends the values to arduino2 through xbee. I also distinguish which pot it was using 'S', 'B', or 'G'. When I was testing earlier, I would ONLY move with the 'B' pot and it would record but it was also recording 'G' pot also when that one was not even being touched. As you can see, it records 'B' correctly and it is suppose to apply the actuator depending on the value of the pot.

11

I would debug the sending end first. It looks to me like the G pot is varying more than 15, whether or not you are touching it.

12

Ok, I will do that soon tonight. I am fairly new to all of this so how would the 'G' pot vary by more than 15 if the pot is not even moving? I have a slide pot attached to a pedal so when the pedal is being pushed it pulls the slide pot. How would it vary by more than 15 if it is not being touched? I will check it out just on the input arduino and see if I get a 'G' value whichout touching it. If so, should I change the difference by greater than 15 to make it stop?

13

The analog reading won't give an exact value.

Also, depending on your wiring, it wouldn't surprise me too much if changing one pedal influenced the other. Say there is resistance in the wiring and you push one pedal. That might deliver slightly less volts to the other pedal, so it gives a lower reading, although not touched by human hands (or feet).

14

ok, I understand now. I will test the inputs into arduino1 here soon when I get back into the lab. And with the bold, more than likely the wiring is affecting it like you mentioned. Is there a way to possible fix that?
Right now, I have a 5V supply to all 3 + pots on the breadboard...what if I supplied each pot it's own 5V source on the breadboard?

15

Well, let's not get ahead of ourselves, solving a problem that may not exist. Take some readings. Confirm whether or not that is the issue.

16

Ok, so I ran the debug for the first arduino that is receiving the inputs and when I start the serial it acts like an infinite loop for the 'B' and 'G' without me even touching anything. This is a small sample. It is getting feedback somehow as the range for 'B' and 'G' are within 20 of highest and lowest.

<B176>
<G67>
<B160>
<B177>
<B160>
<B177>
<G50>
<G66>
<G49>
<G66>
<G50>
<G66>
<B161>
<B178>
<B160>
<B176>
<B160>
<B176>
<G49>
<G66>
<G48>
<G68>
<G49>
<G68>
<B160>
<B177>
<G52>
<G69>
<G49>
17

It certainly seems twitchy doesn't it? I wonder why? Perhaps a capacitor might smooth out the changes. But what changes I wonder? Maybe if you can measure the voltage you can work out whether the pot is actually giving a fluctuating reading, or if this is some artefact of the way that analogRead works.

18 
int potPin = A0; int potPin1 =A1; int potPin2 = A2;

One statement per line, please.

If you are going to send the data read from these pins using the letters S, B, and G, might I suggest that S, B, and G as suffixes makes more sense than nothing, 1, and 2.

int val; int val1; int val2;
int lastVal = 0; int lastVal1=0; int lastVal2=0;

Same issues here.

19

What I have now seems to all work correctly over xbee and the pots are distinguished using S,B,G for steer, brake,gas pots.

That's not the impression I get.

Ok...so what is it I need to change?

int potPinS = A0;
int potPinB = A1;
int potPinG = A2;

is a start. Change the names of val, val1, val2, lastVal, lastVal1, and lastVal2, too.

20

PaulS:

What I have now seems to all work correctly over xbee and the pots are distinguished using S,B,G for steer, brake,gas pots.

That's not the impression I get.

I stated earlier everything was going good, no weird numbers or big jumps. I seperated the 'B' and 'G' to seperate breadboards and it get no interference with the two. Everything is good now with the pot outputs over xbee.

Now my main concern is getting it to talk over simple serial. I am using BMSerial.h and have stated BMSerial brake(5,6) and brake.begin(9600). I try to write to channel 2 of the roboclaw using brake.write(128) or brake.write(255) as for channel 2 the min is 128 and max is 255 to either apply forward or apply reverse on the actuator. It does not seem to be communicating with the 'write' to the roboclaw.