View Full Version : [Question(s)] Baudrate problem

12-14-2011, 06:39 AM
Background: Trying to gather torque readings from Dynamixel RX-64 motors (RS485) using Robotis CM700 controller linked to a laptop running Matlab (RS232).

Problem: Everything was fine, motors moves and feedback are being capture on the laptop. however during testing, motors suddenly became unresponsive. HOWEVER,motor does response (moves and communicates) to firmware program from the same controller i.e hardware are okay (i hope).

upon checking my code, i suspect that the baudrate initialization has a problem and it is causing communication failure between the motors and the controller:

int main(void)
serial_initialize(57600); //for RS232
dxl_initialize( 0,DEFAULT_BAUDRATE); //RS485

default_baudrate has been declare as 1

int dxl_initialize( int devIndex, int baudnum )
printf("baudnum %d \n",baudnum);

float baudrate;
baudrate = 2000000.0f / (float)(baudnum + 1);

printf("baud rate %d \n",baudrate);

if( dxl_hal_open(devIndex, baudrate) == 0 )
return 0;

gbCommStatus = COMM_RXSUCCESS;
giBusUsing = 0;
return 1;

the two printfs here reveals that baudnum=1 (correct) but the baudrate=9216 (which is supposed to be 1000000). even if i replace this line with a baudrate=1000000, it will still come out as baudrate=9216 on the printf and im not sure why.

I'm using:
avr-gcc (WinAVR 20100110) 4.3.3

I hope i did not miss out anything.
Thanks in advance!

12-14-2011, 07:06 AM
printf("baud rate %f \n",baudrate);

Since baudrate is a float.

12-14-2011, 07:12 AM
the controller is not able to print floating point values =/
i'm currently using Roboplus Terminal v1.03 to view the outputs from the controller....

i've revert back to a code that has been untouched weeks before this problem started and it is also unable to communicate with the motors... seems like only the onboard firmware is capable communicating....

12-14-2011, 07:39 AM
The 'DEFAULT_BAUDRATE' preprocessor definition is intended for the AX series (default rate is 1Mbps). If you have not already, you will need to change the Baud Rate register of the RX-64's to '1' (1Mbps) from their default of '34' (57600bps). If you do not want to change the register settings of the RX-64's, then replace 'DEFAULT_BAUDRATE' with '34'.

If the servos respond for some time before failing: 1) check your power supply (can it handle the current and voltage required) and 2) check the cables connecting the servos (the connectors tend to work themselves loose over time, and intermittent shorts/breaks are very annoying/difficult to track down). For #2, just unplug and reconnect all of the connectors. If that does not work, try unplugging different chains of servos and see if there is any combination that seems to work. If it does start working, replace the cable connecting that chain to the bus and test again. Repeat ad nauseum until you have replaced the faulty cable.

12-14-2011, 07:49 AM
@tician: i've unplugged and plugged back everything but still no luck. The current configuration should give me 1Mbps, i've traced it line by line.... but what confuses me is how the :

printf("baud rate %d \n",baudrate);

gives me 9216 instead of a 1000000 even if i should do a


before the printf statement.

just earlier today i was working only on the matlab side of my project when suddenly i realized i'm no longer getting readings from the controller... how wierd

12-14-2011, 07:57 AM
i doubt it is a hardware problem because the monitor mode in the cm-700 firmware is able to move all the motors as per normal.

12-14-2011, 05:19 PM
Why don't you sort out how to print a float value of 1000000.0f. 1000000 seems a very big 16 bit integer to me !
Until you can understand simple embedded C for the avr, and post what other stuff you created. There seems to be little others can do to help.

This doesn't solve your response problem, but might get your feet back on the ground.

12-14-2011, 09:20 PM
from what i understand is that small microcontroller's libraries usually do not support printing of floats due to its complexities. printing it out as an integer would truncate the decimals, which is not useful now....

int main(void)
serial_initialize(57600); //initialize rs232
dxl_initialize( 0, DEFAULT_BAUDRATE ); // initialize rs485, DEFAULT_BAUDRATE=1

sei(); // Interrupt Enable

for( i=0; i<NUM_ACTUATOR; i++ ) //initialize motor id array
id[i] = i+1; // Set ID for num_actuator number of motors
GoalPos[i] = 512; //set all motor GoalPos to middle


update_PresentPosLoad(); //read load & position data from all motors

printf("P,%i,%i,%i,%i\n", PresentLoad[14], PresentLoad[15], PresentLoad[19], PresentLoad[20]); //print values for matlab

}//end infinite while loop

return 0;
}//end int main(void)

before the errors start occuring, i was toying around only with the printf statement, trying to make a desired data packet for matlab to read.

heres the function update_PresentPosLoad. DO note that this function works perfectly fine before the incident. No changes were made to them.

void update_PresentPosLoad(void)
int i=0, tempPos=0, tempLoad=0;

for( i=0; i<NUM_ACTUATOR; i++ )
tempPos = dxl_read_word( (int)id[i], P_PRESENT_POSITION_L ); // Check motors
tempLoad = dxl_read_word( (int)id[i], P_PRESENT_LOAD_L ); // Check motors
PresentPos[i] = tempPos;
PresentLoad[i] = tempLoad; // Store in array