Baud rate issue on Raspberry Pi

[rohbotics]

We have a semi-rare intermittent bug where ubiquity_motor starts an instance of motor_serial near line 90 in motor_hardware.cc.

We have seen that sometimes after many starts from cold power off we get wheels dont work.

Symptoms:

• ROS topic /diagnostics will not be publishing items for 'Firmware Version' or 'Firmware Date' and more because motor_node cannot talk to the MCB
• The ROS log will be riddled with a great many serial errors seen with a reject message with REJECT in the message
• The serial in and serial out leds look normal and keep blinking
• An oscilloscope looking t the serial in to the board from the PI seen on pin 5 of the 6 pin FDDI jack, P508 will show the Pi is running at 115200 buad and not 38400 baud. So pulse widths seen on that pin will be about 8.7 micro sec, not 26 micro sec
• sudo stty -F /dev/ttyAMA0 will show 38400 baud but that is clearly not the rate the Pi is sending at

How to reproduce this bug: (This defect may not happen at all or may happen a high percentage of the time)

• Remove the delay in ubiquity_motor code for motor_hardware.cc very near line 90 if it is in your code. I am removing the extra ROS_INFO statements AND the ros:Duration line so it looks like the code did when we discovered this bug. We keep this code in our repository because it has been seen to help avoid the bug so to better force the bug e revert this out.

• From a cold all off state power up the robot. Wait till serial is initialized which on rev 5.2 boards and later can be seen by the point where the SIN Led, L702, starts to blink very fast. This led is near center top just below the Aux jack 12V pin. Note that a second little led called SOUT blinks right away but the SIN led typically takes 30 sec or more to start blinking.

• After this point there are several ways to see if the bug is active. The simplest way is to tell the robot to move and if it does NOT move then check ros log for a great many words of 'REJECT'.
  Another way is use 'rostopic echo /diagnostics | grep -A 2 -e 'Firmware Date'' and if you see no output check for 'REJECT' message.

Software Seen To Show This Defect:

• This defect has been seen on a Magni with rev 5.2 MCB running a clean 2020-02-10 image on a Raspberry Pi 3B+ cpu

Workaround That generally works:

• If the motor_hardware.cc source file inserts a 2 second delay prior to setup of serial instance this usually fixes the bug. One unit had to have a 4 second delay. The delay is placed near line 90 in the file. A 0.5 sec delay has been show to fix the problem on some units.

[mjstn]

We have done all we can justify at this time to address this issue. We will consider it dealt with by the workaround we have implemented and if it happens again start this as a new issue.

[mjstn]

This is a duplicate of 118 so the meat of comments in this issue will be added to 118 and this one closed now.