Author Topic: Controlling motors [Urgent]  (Read 3474 times)

0 Members and 1 Guest are viewing this topic.

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,653
  • Helpful? 169
    • Society of Robots
Re: Controlling motors [Urgent]
« Reply #30 on: February 10, 2013, 09:01:35 PM »
Can you post the block of code that outputs those values?

And please please comment your code. It's hard to understand what's going on. :P

read through a few of these posts:
https://www.google.com/search?q=good+code+commenting+rules

ps - It's better to post just the relevant code, instead of ALL of it, because it makes it easier for us to just zoom in on the important stuff. But don't abbreviate your code too much, because then we might not see the mistake right next to it ;D

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #31 on: February 10, 2013, 09:25:50 PM »
Ok sorry about that.  I thought I commented it enough.  Here is the block of code I BELIEVE is incorrect.  I have tested the Xbees and they are working properly
Code: [Select]
#include "hardware.h"

#define XBee_Controlled

#define UART0_TX_BUFFER_SIZE 80
#define UART0_RX_BUFFER_SIZE 80


// Initialize the hardware
void appInitHardware(void) {

initHardware();  //Initialize all hardware including uarts

#ifdef XBee_Controlled
rprintfInit(debugSendByte);  //Send output to computer through FTDI

delay_ms(100);
#endif
rprintf("\nHardware initialized.\n\n"); 
}


// Initialise the software
TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
rprintf("\nAxon Initiated.\n\n");

}

// This is the main loop
TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart) {

uint16_t tempbyte = NULL;

#ifdef XBee_Controlled
if(!uartReceiveBufferIsEmpty(UART0)) {
tempbyte = uartGetByte(UART0);  //Get byte from Xbee
rprintf(“\n tempbyte is: %d”, tempbyte);  //Tempbyte is __
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
TICK_COUNT ms = loopStart / 1000; // Get current time in ms
int16_t now = ms % (TICK_COUNT)10000; // 10 sec for a full swing
if(now >= (int16_t)5000){ // Goes from 0ms...5000ms
now = (int16_t)10000 - now; // then 5000ms...0ms
}

return 0;
}

I just put all the code in there before so it's all there in case you need to look somewhere
« Last Edit: February 10, 2013, 09:38:54 PM by Mastermime »

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,653
  • Helpful? 169
    • Society of Robots
Re: Controlling motors [Urgent]
« Reply #32 on: February 10, 2013, 09:47:31 PM »
A few notes:

You can define this in Project Designer, in the UART:
Code: [Select]
#define UART0_TX_BUFFER_SIZE 80
#define UART0_RX_BUFFER_SIZE 80

Use %u for uint16, not %d (which is for signed).
Code: [Select]
rprintf(\n tempbyte is: %d, tempbyte);
. . . but that shouldn't be the source of your problems.

This is your setup, right?

PS controller -> arduino -> Xbee -> the other Xbee -> Axon -> USB -> hyperterminal

Is it possible the Arduino isn't outputting the correct data?

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #33 on: February 10, 2013, 09:55:08 PM »
Quote
Use %u for uint16, not %d (which is for signed).

I will change that


Quote
PS controller -> arduino -> Xbee -> the other Xbee -> Axon -> USB -> hyperterminal
I think this is what you mean but Axon (UART3) > ftdi > hypertrm

Quote
Is it possible the Arduino isn't outputting the correct data?
I dont think so.  I checked the output from the xbee on the robot and it is correct

Quote
25625625625612752525252525252525252525252511127891271271271271271271271271279294127127127127127127127127127127
I dont have to say new line everytime I send a byte right?  I dont think so.  Could it be my UART port that is not working (unlikely)?
« Last Edit: February 10, 2013, 09:56:49 PM by Mastermime »

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,653
  • Helpful? 169
    • Society of Robots
Re: Controlling motors [Urgent]
« Reply #34 on: February 10, 2013, 10:02:33 PM »
Quote
Is it possible the Arduino isn't outputting the correct data?
I dont think so.  I checked the output from the xbee on the robot and it is correct
Can you post here the output? Or is that the example below?

Quote
25625625625612752525252525252525252525252511127891271271271271271271271271279294127127127127127127127127127127
I dont have to say new line everytime I send a byte right? Could it be my UART port that is not working (unlikely)?
You don't need a new line each time. But for debugging purposes, could you add a space between each value transmitted? I can't tell if you are sending a '56', or a '25', etc.

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #35 on: February 10, 2013, 10:08:56 PM »
Quote
Can you post here the output? Or is that the example below?
The first few are:
256 
256
256
127
127

Split up in threes at first
Should be adequate enough
« Last Edit: February 10, 2013, 10:16:27 PM by Mastermime »

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,653
  • Helpful? 169
    • Society of Robots
Re: Controlling motors [Urgent]
« Reply #36 on: February 10, 2013, 10:19:00 PM »
Well, if I break it up into 3's I get this:
256 256 256 256 127 525 252

Do you see the 525 in there? That looks suspicious to me . . .

Can you post the block of code that transmits these values on the Arduino to the Xbee? (and also the part where you printed out those numbers above?)

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #37 on: February 10, 2013, 10:31:48 PM »
I cant remember exactly, but I think I may have touched a joystich which either read as 52 or 5.  I cant remember.  I know that the Xbees are properly sending bytes though.  I wouldn't waste your time on that.  I dont have the output with lines inbetween anymore either.  I have tested that multiple times though.

How can something so simple (receiving bytes) go so wrong?   >:(
« Last Edit: February 10, 2013, 11:47:21 PM by Mastermime »

Offline newInRobotics

  • Supreme Robot
  • *****
  • Posts: 1,015
  • Helpful? 48
  • N.I.R.
Re: Controlling motors [Urgent]
« Reply #38 on: February 11, 2013, 11:09:07 AM »
Did you check baud rates of both devices? Do they match? Did You check that selected baud rates match well with respective clock to produce lowest error possible?
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." - Kristian W

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #39 on: February 11, 2013, 03:37:28 PM »
Quote
Did you check baud rates of both devices? Do they match?

I just checked The baud rates and they match and are set at 38400.

Quote
Did You check that selected baud rates match well with respective clock to produce lowest error possible?

No I did not.  I just set the highest baud rate I could.  This wouldnt be the source of my problem, would it?




Admin:  I dont think that is the problem.  Let me reiterate, for some reason the Axon is taking the data and twisting into three different numbers depending on the command I press.

example when i press triangle
tempbyte is: 50
tempbyte is: 53
tempbyte is: 54

« Last Edit: February 13, 2013, 03:55:54 PM by Mastermime »

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #40 on: February 11, 2013, 05:06:57 PM »
I just noticed something.  I dont have anything connected to the ground port on UART.  Should that be connected to common?

EDIT: That wasn't it
« Last Edit: February 11, 2013, 05:48:55 PM by Mastermime »

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,132
  • Helpful? 108
Re: Controlling motors [Urgent]
« Reply #41 on: February 11, 2013, 06:12:49 PM »
I guess I'm being a bit dump (never used XBee etc) but you talk in your original post about 'PS2 controller over XBee'. Hence I'm not sure what s/w is running on the cpu - ie is it using WebbotLib PS/2 controller code or is the whole XBee thing just sending a serial command to a UART which you are trying to make sense of? If its the latter then connecting straight into HyperTerminal, or others, would show would what's being received.

As always - a copy of your .prj file might help (me!) or at least the PDF output from ProjectDesigner (menu option File|Print).
Apologies if it seems dumb - but don't forget like Admin asked re code commenting - you have lived/breathed this project and know what is what and how it all hangs together. We are totally blind and so you must bear with us and help us to 'see' your set up in detail .

For example when you say:
Quote
Code: [Select]
This is what its supposed to be

    #define TRIANGLE 256
    #define START 257
    #define L2 258
    #define R2 259


Who says so? Where do these values come from?

Sorry - just trying to go back to first principles.
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #42 on: February 11, 2013, 06:24:11 PM »
Quote
is the whole XBee thing just sending a serial command to a UART which you are trying to make sense of? If its the latter then connecting straight into HyperTerminal, or others, would show would what's being received.

This is correct.  I connected UART3 to Hyperterminal (where I sent my rprintf).  But thats where Im getting numbers like 50, 53, 54.  I will post the output I get directly from the Xbee receiver on the robot so you guys can see

Quote
Apologies if it seems dumb - but don't forget like Admin asked re code commenting - you have lived/breathed this project and know what is what and how it all hangs together. We are totally blind and so you must bear with us and help us to 'see' your set up in detail .

Oh I understand completely.  That's why I included all my code at first.

Quote
Who says so? Where do these values come from?

Sorry - just trying to go back to first principles.

Thats what I defined "When I press triangle, send 256" in my Arduino code

Arduino Output directly from Xbee on Robot (receiver)
Quote
25625625625625625625625625625625625625625625625625625625625625625625625625625625
62572572572572572572572572572572572572572572572572572572572572572572572572572572
59259259259259259259259259259259259259259259259259259259259259259259259259259259
25825825825825825825825825825825825825825825825825825825825825825825825825825825
82092552552552552552552552552552552552552552552552552552552552552552552552552552
10188128128128128128128128128128128128128128128128128128128128128128128128128128
12712712712712712712712712712712712712712712712712712712712712712712712712712752
461111111111111111111111111111111111111111111111111111111111111111111111111111
first line: 256 triangle
second line:257 start
next two lines: left trigger and right trigger
rest of lines: joystick commands
« Last Edit: February 11, 2013, 06:35:18 PM by Mastermime »

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,132
  • Helpful? 108
Re: Controlling motors [Urgent]
« Reply #43 on: February 11, 2013, 08:18:33 PM »
Ok think I'm getting there....

Quote
example when i press triangle
tempbyte is: 50
tempbyte is: 53
tempbyte is: 54


If you look at the ascii codes (http://www.asciitable.com/) for 50,53, 54 then you get '2', '5', '6' respectively.
So your sender is sending ascii characters but you are printing them out in decimal.

you could probably prove this by changing your printf to print them as characters instead ( note the %c, the '(char)' is probably optional)
Code: [Select]
rprintf(\n tempbyte is: %c, (char)tempbyte);  //Tempbyte is __

So for '256' you are receiving three separate bytes/chars. You will have to write code on your receiver to parse it back into a number (int say).
Hopefully your sender either has a delimiter between numbers, or always uses 3 character bytes, otherwise you wont know when one number ends and the next begins. eg is
"256123456"
parsed as 256, 123, 456 or as 256,12, 345,6 etc etc

-- edit --
Alternatively you could change the Arduino code to send them as numbers, not text, but then you could only use numbers in the range 0 to 255 (to fit into a byte)
« Last Edit: February 11, 2013, 08:42:53 PM by Webbot »
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #44 on: February 11, 2013, 10:22:30 PM »
Wow...  I cannot believe this is finally solved.  Thank you sir so much.  You are a genius!  How can I repay you?   I will test and let you guys know how everything goes tomorrow   :D :D :D :D :D

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,653
  • Helpful? 169
    • Society of Robots
Re: Controlling motors [Urgent]
« Reply #45 on: February 12, 2013, 11:56:00 AM »
Quote
If you look at the ascii codes (http://www.asciitable.com/) for 50,53, 54 then you get '2', '5', '6' respectively.

I was suspecting the problem to be the Arduino code, too, but I wouldn't have figured the above out given the available information in a million years lol  :o


Referring to other questions . . . if it was the wrong baud rate, you'd get random crazy characters, or none at all. As for ground, you need *a* ground connected. I included one for each UART to serve as a reminder and as an extra pin. But any ground on the Axon is ok. If ground wasn't connected, you'd like not get any data at all.

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #46 on: February 12, 2013, 01:11:53 PM »
Quote
if it was the wrong baud rate, you'd get random crazy characters, or none at all.  As for ground, you need *a* ground connected. I included one for each UART to serve as a reminder and as an extra pin. But any ground on the Axon is ok. If ground wasn't connected, you'd like not get any data at all.

Yeah that's what I thought would happen with the bauds and grounds.  Thanks a lot for your help Admin.  Much appreciated



Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,132
  • Helpful? 108
Re: Controlling motors [Urgent]
« Reply #47 on: February 12, 2013, 01:36:54 PM »
The other thing I noticed in your project was an output pin E5 called 'Xbee5v'. I presume you are not using this to provide power to the XBee ? That could be bad and blow the pin, or worse, if the XBee needs more power than the cpu can provide. Either use a 5v regulated supply pin or, if you want to turn supply to the XBeee on and off, then you should use the pin to control either a relay or a MOSFET to do it.
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #48 on: February 12, 2013, 01:40:45 PM »
Yeah I'm not using E5.  This was a mistake.  I am supplying the Xbee with a regulated 5v.  I should delete that

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #49 on: February 13, 2013, 06:09:19 PM »
Everything is working great!   :D :D

EDIT: but i still get occasional buffer overflow and then everything goes haywire.  I took out all my rprintfs.  Should I increase the buffer to 120 or 130?  Can I do this in my code or do I have to go back into Project Designer and do it?  Right now I have it set in my c file and in pd to 80/80
« Last Edit: February 13, 2013, 07:00:22 PM by Mastermime »

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,653
  • Helpful? 169
    • Society of Robots
Re: Controlling motors [Urgent]
« Reply #50 on: February 13, 2013, 08:01:14 PM »
You just need to slow down your rprintf's and use the max baud rate. Adding small delays usually does the job for me.

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #51 on: February 13, 2013, 08:14:11 PM »
Ok I commented out all my rprintfs so that shouldnt be a factor.  Small delays in the Arduino code right?  Yeah I'm doing a bit of research.  I dont understand buffers completely, but I notice a lot of people have like 20/40.  I'm using the max baud rate of 38400.

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,653
  • Helpful? 169
    • Society of Robots
Re: Controlling motors [Urgent]
« Reply #52 on: February 13, 2013, 08:17:35 PM »
Buffer overflow errors are from either receiving or sending data by UART too fast. If your Arduino is sending too fast, slow it down, etc.

Adding a simple delay_ms(10); in your main while loop might be all that's needed. Or if the Arduino, however they do it.

Ok I commented out all my rprintfs so that shouldnt be a factor.  Small delays in the Arduino code right?  Yeah I'm doing a bit of research.  I dont understand buffers completely, but I notice a lot of people have like 20/40.  I'm using the max baud rate of 38400.

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #53 on: February 13, 2013, 08:37:56 PM »
oh ok thats what I was thinking.  Thanks

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,132
  • Helpful? 108
Re: Controlling motors [Urgent]
« Reply #54 on: February 14, 2013, 12:30:31 PM »
The reason it goes 'mad' is because, due to the overflow, you have missed one or more characters and so your parsing routine probably gets confused. Its usually a good idea to have some sort of delimiter between the number (ie spaces or commas say) - your parsing routine can then reset itself when it receives a delimiter to expect the start of a new number.

Other alternatives are to not constantly keep xmiting the same info  from the Arduino. eg don't keep saying that a button is down/up - just send a msg when the button is pressed and then another when it is released.
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #55 on: February 17, 2013, 04:14:45 PM »
Awesome! I just added the delimiter and my problem is solved.  thanks Webbot.

Actually I just ran into a problem.  For some reason, I cannot run both motors at a time.  Check out the video to see what I mean.


VoltX Wireless Test 5


Code I was using

Code: [Select]
#include "hardware.h"

#define XBee_Controlled

#define UART0_TX_BUFFER_SIZE 80
#define UART0_RX_BUFFER_SIZE 80

#define TRIANGLE 256
#define START 257
#define L2 258
#define R2 259

#define MOTOR_L_MIN 1
#define MOTOR_L_STOP 64
#define MOTOR_L_MAX 127
#define MOTOR_R_MIN 128
#define MOTOR_R_STOP 192
#define MOTOR_R_MAX 255
#define SIGNAL_MOTORS_OFF 0

uint16_t motorLCurVal;
uint16_t motorRCurVal;
uint16_t motorLTarVal;
uint16_t motorRTarVal;
uint16_t motorVal;

boolean receiving;
#define PACKET_SIZE 3
char packet[] = {0, 0, 0};
int curByte;

// Initialize the hardware
void appInitHardware(void) {

initHardware();

#ifdef XBee_Controlled
rprintfInit(debugSendByte);
delay_ms(10);
#endif

//rprintf("\nHardware initialized.\n\n");
}


// Initialise the software
TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
//rprintf("\nAxon Initiated.\n\n");
receiving = false;
motorLCurVal = motorLTarVal = MOTOR_L_STOP;
motorRCurVal = motorRTarVal = MOTOR_R_STOP;
curByte = 0;
}

// This is the main loop
TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart) {

uint16_t tempbyte = NULL;

#ifdef XBee_Controlled
if(!uartReceiveBufferIsEmpty(UART0)) {
char temp = uartGetByte(UART0);
if (temp == 'A' && !receiving)  //delimiter
{
receiving = true;
curByte = 0;
}
else
{
packet[curByte] = temp;
//rprintf(“Got a byte! %c\n”, temp);
if (curByte == (PACKET_SIZE - 1) )
{
tempbyte = atoi(packet);  //atoi = convert string to packet
receiving = false;
}
curByte++;
}
}
#endif
   

if (tempbyte != NULL) {

if (tempbyte >= MOTOR_L_MIN && tempbyte <= MOTOR_R_MAX)
{
setMotorSpeed(tempbyte);
}
else if (tempbyte== START)
{
pin_toggle(Remoteswitch_relay);
}
else if (tempbyte== TRIANGLE)
{
pin_toggle(led1);
pin_toggle(led2);
pin_toggle(led3);
}

tempbyte = NULL;
}
else
{
motorStopMotor();
}


/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
TICK_COUNT ms = loopStart / 1000; // Get current time in ms
int16_t now = ms % (TICK_COUNT)10000; // 10 sec for a full swing
if(now >= (int16_t)5000){ // Goes from 0ms...5000ms
now = (int16_t)10000 - now; // then 5000ms...0ms
}
return 0;
}


//All the ++ and -- is just to make the robot gradually stop and start
//motorXCurVal is the current speed.
//motorXTarVal is where we want the speed to be.

void motorStopMotor()
{
do {
if (motorLCurVal<MOTOR_L_STOP)
{
motorLCurVal=motorLCurVal+1;
}
else if (motorLCurVal>MOTOR_L_STOP)
{
motorLCurVal=motorLCurVal-1;
}

Sabertooth_uartSendByte(motorLCurVal);
//rprintf("\n StopmotorLCurVal is: %d", motorLCurVal);

if (motorRCurVal<MOTOR_R_STOP)
{
motorRCurVal=motorRCurVal+1;
}
else if (motorRCurVal>MOTOR_R_STOP)
{
motorRCurVal=motorRCurVal-1;
}

Sabertooth_uartSendByte(motorRCurVal);
delay_ms(10);

} while (motorLCurVal!=MOTOR_L_STOP && motorRCurVal!=MOTOR_R_STOP);
}

void setMotorSpeed(uint16_t byte)
{
if (byte >= MOTOR_L_MIN && byte <= MOTOR_L_MAX)
{
motorLTarVal = byte;
do {
if (motorLCurVal < motorLTarVal)
{
Sabertooth_uartSendByte(++motorLCurVal);
}
else
{
Sabertooth_uartSendByte(--motorLCurVal);
}

} while (motorLCurVal != motorLTarVal);
}
else if (byte >= MOTOR_R_MIN && byte <= MOTOR_R_MAX)
{
motorRTarVal = byte;
do {
if (motorRCurVal < motorRTarVal)
{
Sabertooth_uartSendByte(++motorRCurVal);
}
else
{
Sabertooth_uartSendByte(--motorRCurVal);
}
delay_ms(10);

} while (motorRCurVal != motorRTarVal);
}
}

« Last Edit: February 18, 2013, 04:13:41 PM by Mastermime »

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,132
  • Helpful? 108
Re: Controlling motors [Urgent]
« Reply #56 on: February 18, 2013, 09:07:37 PM »
Just looking at your code:-
The atoi function looks at data in packet - but suppose you've just written a '6' and '4' in there. The answer to atoi will be 64? Not always- if it previously had '256' then it will now have '646'. The '64' being new and the trailing '6' being old stuff.

So you need to make sure that since 'packet' is being treated as a string that you write a zero terminator in there.
change
Code: [Select]
char packet[] = {0, 0, 0}; to
Code: [Select]
char packet [PACKET_SIZE+1] to allow for this extra 'end of string char'

Then change:
Code: [Select]
packet[curByte] = temp; to add the end of string character ie
Code: [Select]
packet[curByte] = temp; packet[curByte+1]='\0';
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline MastermimeTopic starter

  • Supreme Robot
  • *****
  • Posts: 314
  • Helpful? 5
Re: Controlling motors [Urgent]
« Reply #57 on: February 18, 2013, 11:41:39 PM »
You would be correct if I didn't buffer every number with 0's. but like for 64, I actually send 064. So it always is full with the correct #. You wouldn't know this b/c its on the arduino side of things. Not thats its bad practice, but thats not our problem for the packet response. Helpful though.  Sorry I should've mentioned that. 

When this odd phenomenon occurs, the red led on the Sabertooth lights up.  I dont think this is the source of my problem because I believe that lights due to high startup current.  This is very odd.  I've had a lot of odd problems!

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,653
  • Helpful? 169
    • Society of Robots
Re: Controlling motors [Urgent]
« Reply #58 on: February 19, 2013, 12:15:44 AM »
Quote
I dont think this is the source of my problem because I believe that lights due to high startup current.
To verify the hardware isn't the problem, write a simple program that commands both motors to run together.

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,132
  • Helpful? 108
Re: Controlling motors [Urgent]
« Reply #59 on: February 19, 2013, 11:59:54 AM »
You would be correct if I didn't buffer every number with 0's. but like for 64, I actually send 064. So it always is full with the correct #. You wouldn't know this b/c its on the arduino side of things. Not thats its bad practice, but thats not our problem for the packet response. Helpful though.  Sorry I should've mentioned that. 

Yes - but you are storing the three digits in memory and the 'atoi' function keeps on going until it finds something that is not a digit. ie 'atoi' works with a string not an array of characters. A string is the same as an array of characters except that it has an extra zero at the end to makrk the end of the string.

You probably have no idea what data is living in memory immediately after the 3 'packet' bytes.
For example: if you had
char packet[3] = { '0','0','1'} and this was followed in memory by something else say like:
char foobar[] = { '3', '2', '1'}
then when you do 'atoi(packet)' you would get back 1321 which is probably not what you expect.

Even worse foobar could be a variable and so the atoi may sometimes do what you want and at other times not.

Don't forget - only the compiler know that 'packet' is 3 digits long - at runtime the 'atoi' function just takes its first byte to be the start of a, potentially, infinitely long list of characters.

To fix your code then you MUST declare packet as 4 bytes rather than 3 and make sure that the last byte is a zero (ie the number 0 not the character '0' - ie you can use packet[3]=0 or packet[3]='\0')


Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

 


Get Your Ad Here

data_list