Don't ad-block us - support your favorite websites. We have safe, unobstrusive, robotics related ads that you actually want to see - see here for more.
0 Members and 1 Guest are viewing this topic.
#include "hardware.h"#define XBee_Controlled#define UART0_TX_BUFFER_SIZE 80#define UART0_RX_BUFFER_SIZE 80// Initialize the hardwarevoid appInitHardware(void) { initHardware(); //Initialize all hardware including uarts #ifdef XBee_Controlled rprintfInit(debugSendByte); //Send output to computer through FTDIdelay_ms(100); #endifrprintf("\nHardware initialized.\n\n"); }// Initialise the softwareTICK_COUNT appInitSoftware(TICK_COUNT loopStart){rprintf("\nAxon Initiated.\n\n"); }// This is the main loopTICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart) { uint16_t tempbyte = NULL; #ifdef XBee_Controlled if(!uartReceiveBufferIsEmpty(UART0)) { tempbyte = uartGetByte(UART0); //Get byte from Xbeerprintf(“\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;}
#define UART0_TX_BUFFER_SIZE 80#define UART0_RX_BUFFER_SIZE 80
rprintf(ā\n tempbyte is: %dā, tempbyte);
Use %u for uint16, not %d (which is for signed).
PS controller -> arduino -> Xbee -> the other Xbee -> Axon -> USB -> hyperterminal
Is it possible the Arduino isn't outputting the correct data?
25625625625612752525252525252525252525252511127891271271271271271271271271279294127127127127127127127127127127
QuoteIs 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
25625625625612752525252525252525252525252511127891271271271271271271271271279294127127127127127127127127127127I dont have to say new line everytime I send a byte right? Could it be my UART port that is not working (unlikely)?
Can you post here the output? Or is that the example below?
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?
Code: [Select]This is what its supposed to be #define TRIANGLE 256 #define START 257 #define L2 258 #define R2 259
This is what its supposed to be #define TRIANGLE 256 #define START 257 #define L2 258 #define R2 259
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.
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 .
Who says so? Where do these values come from?Sorry - just trying to go back to first principles.
25625625625625625625625625625625625625625625625625625625625625625625625625625625625725725725725725725725725725725725725725725725725725725725725725725725725725725925925925925925925925925925925925925925925925925925925925925925925925925925925925825825825825825825825825825825825825825825825825825825825825825825825825825825820925525525525525525525525525525525525525525525525525525525525525525525525525521018812812812812812812812812812812812812812812812812812812812812812812812812812812712712712712712712712712712712712712712712712712712712712712712712712712712752461111111111111111111111111111111111111111111111111111111111111111111111111111
example when i press triangletempbyte is: 50tempbyte is: 53tempbyte is: 54
rprintf(ā\n tempbyte is: %cā, (char)tempbyte); //Tempbyte is __
If you look at the ascii codes (http://www.asciitable.com/) for 50,53, 54 then you get '2', '5', '6' respectively.
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.
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.
#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 0uint16_t motorLCurVal;uint16_t motorRCurVal;uint16_t motorLTarVal;uint16_t motorRTarVal;uint16_t motorVal;boolean receiving;#define PACKET_SIZE 3char packet[] = {0, 0, 0};int curByte;// Initialize the hardwarevoid appInitHardware(void) { initHardware(); #ifdef XBee_Controlled rprintfInit(debugSendByte); delay_ms(10); #endif //rprintf("\nHardware initialized.\n\n");}// Initialise the softwareTICK_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 loopTICK_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); }}
char packet[] = {0, 0, 0};
char packet [PACKET_SIZE+1]
packet[curByte] = temp;
packet[curByte] = temp; packet[curByte+1]='\0';
I dont think this is the source of my problem because I believe that lights due to high startup current.
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.