CRC errors/time-outs reading encoders
CRC errors/time-outs reading encoders
I'm connected using USB so not sure if noise is an issue. All of the other commands I've been sending seem ok. The first time I request encoder counts for both channels, I see a lot of retries (timeouts and CRC errors). This is before the motors are even moving. Once it gets past that, it seems OK. RoboClaw 2x15 V5.
I also noticed the example code was sending a CRC with the read command which seems incorrect.
I see in the spec that no CRC is sent with read commands or commands that do not send any data. I had to change the example code to not send the CRC which made it work.
95 - Read Settings from EEPROM
Read all settings from non-volatile memory.
Send: [Address, 95]
Receive: [Enc1Mode, Enc2Mode, CRC(2 bytes)]
I also noticed the example code was sending a CRC with the read command which seems incorrect.
I see in the spec that no CRC is sent with read commands or commands that do not send any data. I had to change the example code to not send the CRC which made it work.
95 - Read Settings from EEPROM
Read all settings from non-volatile memory.
Send: [Address, 95]
Receive: [Enc1Mode, Enc2Mode, CRC(2 bytes)]
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: CRC errors/time-outs reading encoders
1. Make sure you are using firmware 4.1.16
2. Are you using our Python library to talk to the Roboclaw or something your rolled on your own? If you rolled your own please provide the code.
3. Which example were you using that was sending a CRC(to the Roboclaw) with a read command. Read commands return a CRC only.
2. Are you using our Python library to talk to the Roboclaw or something your rolled on your own? If you rolled your own please provide the code.
3. Which example were you using that was sending a CRC(to the Roboclaw) with a read command. Read commands return a CRC only.
Re: CRC errors/time-outs reading encoders
I have 4.1.16 f/w.
I was wrong about sending CRC during read request. It's something else.
I'm using the Arduino library in my c/c++ app on a Raspberry Pi (changed to using file i/o to /dev/tty...).
See my comment in the code below. I didn't see that behavior documented.
Anyway. My CRC issue seems to be resolved.
Code snip is from RoboClaw.cpp
I was wrong about sending CRC during read request. It's something else.
I'm using the Arduino library in my c/c++ app on a Raspberry Pi (changed to using file i/o to /dev/tty...).
See my comment in the code below. I didn't see that behavior documented.
Anyway. My CRC issue seems to be resolved.
Code snip is from RoboClaw.cpp
Code: Select all
uint8_t RoboClaw::Read1(uint8_t address,uint8_t cmd,bool *valid){
uint8_t crc;
if(valid)
*valid = false;
uint8_t value=0;
uint8_t trys=MAXRETRY;
int16_t data;
do{
flush();
crc_clear();
write(address);
crc_update(address); // << The sent address and command included in response CRC??
write(cmd);
crc_update(cmd);
data = read(timeout);
crc_update(data);
value=data;
if(data!=-1){
uint16_t ccrc;
data = read(timeout);
if(data!=-1){
ccrc = data << 8;
data = read(timeout);
if(data!=-1){
ccrc |= data;
if(crc_get()==ccrc){
*valid = true;
return value;
}
}
}
}
}while(trys--);
return false;
}
- Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: CRC errors/time-outs reading encoders
If your CRC is fixed did the timeout problem also correct itself or is that still and issue?
Yes, the returned CRC from a read command is calculated using the address and command byte received by the Roboclaw plus the data sent back from the roboclaw. This covers possible commuications errors in the address/command bytes sent which may have still looked like a valid command to the roboclaw.
Also, we usually recommend using the python library with a R-Pi since it is already setup to work on linux machines but I dont see any reason what you did(modifying the arduino C++ library) would be a problem. I dont think there is any arduino specific code in the arduino library anymore though you may find a gotcha or two at some point.
Yes, the returned CRC from a read command is calculated using the address and command byte received by the Roboclaw plus the data sent back from the roboclaw. This covers possible commuications errors in the address/command bytes sent which may have still looked like a valid command to the roboclaw.
Also, we usually recommend using the python library with a R-Pi since it is already setup to work on linux machines but I dont see any reason what you did(modifying the arduino C++ library) would be a problem. I dont think there is any arduino specific code in the arduino library anymore though you may find a gotcha or two at some point.