UbiquityRobotics / ubiquity_motor

Package that provides a ROS interface for the motors in UbiquityRobotics robots
BSD 3-Clause "New" or "Revised" License
25 stars 24 forks source link

MotorSerial::transmitCommands uses a hard coded 2 millisec delay for MCB groups of commands #91

Open mjstn opened 4 years ago

mjstn commented 4 years ago

Found this deep in the mud. We can be jamming commands down the throat of the MCB faster than it can process them in all cases of worse case delay. This is likley 'part' of something that was recently discussed as a reliability issue by a user of our code on a different platform than the raspberry Pi platform. In any case this should be fixed to avoid message overrun on mcb.

mjstn commented 4 years ago

Here is what will be tried first for a robust yet time-out-able protocol that will be backward compatible with old firmware.

The ACK Protocol. Here is what I am coding now

mjstn commented 4 years ago

As of today I have in branch addMcbMessageAck a good 1st cut attempt to solve 95% or more of issues. My goal at this time is to have host side code that will function and improve things even with prior firmware. Then firmware can also be helping this situation with perhaps v38 by setting a busy bit. At this time host code on any read will set a 'mcb busy' condition upon and sending of a read query to the MCB. The host will on any read look at the new mcb is busy bit which is the upper 0x80 bit of register byte. Host will set no longer busy if it sees this bit clear. This is 1/2 of a formal solid solution. After v38 we will have MCB report this bit back to host for each reply. To use v38 host code MUST be current so we can mask off register byte with 0x7F. So we will send out host code first then REQUIRE host upgrade for usage of v38.