USB error upon running ./startRobot.sh

[henryclever]

USB error upon running ./startRobot.sh

[cbarrett27]

I'm getting this same error as well. Thanks for all the work you've done as well Chris!

[chrisl8]

Should be fixed now, along with a few other issues.

You can run the Quick Install again, or you can just
cd ~/catkin_ws/src/ArloBot/
git pull

Although I found some other issues that might miss, but if it works.

Keep the issues coming! 👍

[cbarrett27]

Thanks Chris! Will give it a try

[henryclever]

Chris,

I'm now able to use the Arlobot/scripts/start-robot.sh to receive data from the robot and use Arlobot/scripts/keyboard-teleop.sh to send it data, whilst viewing it all on a rostopic. Still can't use the Arlobot/startRobot.sh, but I don't need the GUI so that is OK. Currently, the robot does not move when I send it a target velocity with the keyboard, but this problem is within the propeller C code and I have a hunch it is a result of not having the relay board, IR sensors, or ultrasonics connected, so I'll go through and try to edit the code. We aren't planning to use these sensors. I'm pleased with the progress as a result of your fix! Thank you!

Henry C.

[chrisl8]

It should work fine without the relay board, especially with the new DHB-10, because it does not rely on the relay board for proper startup sequence anymore. Although a bug is always possible.

Make sure the settings in arlobot.yaml and per_robot_settings_for_propeller_c_code.h in ~/.arlobot are correct.

Also, if you have ROS running be sure to monitor rostopic echo serial.
The two questions are:

1. WITHOUT keyboard teleop running, are there any lines like out: s,0.0,0.0 it means that the ROS code is forcing the robot to stay still. Usually this is something like the plugged in monitor or something.
   If you want to force these out: s,0.0,0.0 lines run ~/catkin_ws/src/ArloBot/scripts/keyboard-teleop.sh which will spit out constant "be still" commands as long as you aren't pushing any keys.

on the other hand

2. What does the propeller board say it is doing on the lines like this:
   in: s 1 1 0 51 200 2 4.08 4.03 0 0
   If the first 1 is a 0, it means the propeller board won't move the robot forward.
   The 2nd one is fore reverse. The full list of meanings is:
   safeToProceed, safeToRecede, Escaping, abd_speedLimit, abdR_speedLimit, minDistanceSensor, leftMotorPower, rightMotorPower, cliff, floorO

There are some details about this in This is all explained in ~/catkin_ws/src/ArloBot/scripts/direct2PropSerialTestLines.txt

So if the first number is a 0, then yes, the propeller C code is refusing to move the robot forward because it thinks a PING sensor is blocked.

Also, if the C code is polling a nonexistent PING sensor, or one that is just unplugged, it will get a ZERO distance reading, which would block the robot.

If that is the case, it should be easy to hack the propeller code to skip the blocking sequence and reload it.
It should work by just setting there to be no PING sensors in ~/.arlobot/per_robot_settings_for_propeller_c_code.h and reloading it, but I haven't tested that scenario recently.

[chrisl8]

P.S. If you can get the web interface to work it will really help. One of the primary reasons I built it was to be able to monitor all of these outputs and inputs from a single graphic interface instead of having to constantly run commands in terminals to pick up dozens of bits if data from all over the place.

[cbarrett27]

Finally got the PING sensors working and keyboard teleop working, but only after i copied the per_robot_settings_for_propeller_c_code.h file into same directory as the propellor .c files.

i'm not able to get the web UI running yet. i'm double checking i have all pre-reqs installed.
then i'm going to get the xbox controller working (yea!)

thanks Chris!

[henryclever]

Chris,

This instructions were very helpful. I got everything up and running in ROS including the web based GUI. It now sends correct commands to the propeller via serial when I use the keyboard or the web interface.

However, an issue I am still encountering is that the wheels move erratically when I send a command. For example, if there is a single forward command, they immediately turn on at a high speed and do not turn off when the forward button is released. If the back button is depressed (or clicked on GUI) then the wheels alternately pulse in a seemingly nonsensical way.

When I ran a simple motor test using the following code, the wheels turn at the correct speed:
int main() // Main function
{
drive_feedback(0); // Disable encoders
drive_speed(20, 20); // 20/127 of full power to motors
}

However, if drive_feedback(0) is commented out, then the wheels turn in a similarly erratic speed as described above. I think the problem is somewhere in the propeller code as I'm sure it is getting the right signal serially, but I just don't know what is going on. I modified the arlobot.yaml and per_robot_settings_for_propeller_c_code.h as per instructions but the problem persists.

Thank you for your help. :)

Henry C.

[chrisl8]

Which motor controller(s) are you using?
The "drive_speed(20, 20);" line is only used in the HB25 code.
If you have a DHB-10, are you sure you are using the right propeller code file?

[henryclever]

Chris,

I am using the DHB-10 and I am sure it is the right propeller file. Appears that the 'drive_speed(20, 20) works for this controller as well.

Henry C.

[henryclever]

I dug in more deeply and found that the encoders weren't registering, and found that the black discs were rubbing against the side of the encoder. Both of them were clogged with plastic residue from the discs wearing off into where the IR emits light. This problem is caused by poor tolerances in manufacturing. So, I rigged up a solution by adding extra washers in the hex bolts and a larger washer around the driveshaft to add a millimeter of clearance. This allowed the encoder connected to motor 1 to work as expected, however, motor 2 still did not register any 'ticks' upon testing. FYI, here is the code I used:

http://learn.parallax.com/tutorials/robot/arlo/arlo-activity-board-brain/test-correct-activity-board-electical-connections-3

Thinking the problem was one of the encoder assemblies, I swapped them just to be sure and surprisingly, motor 1's encoder still worked fine but motor 2 did not. I also made sure all encoder assemblies had power, which they did. Thus, I believe issue is in the encoder receiving end of the DHB-10 where motor 2 is connected. I checked and double checked this and I am sure that both encoder assemblies work, and the problem is in the DHB-10. Re-uploaded firmware to no avail. Next plan is to bring in my logic analyser (at home, I'm at office) and compare encoder data signals.

This makes two significant issues with the stock kit, on top of the fact that multiple wires, screws, and nuts were missing from the kit when I bought it. I'm quite displeased this, but really appreciate your efforts in this ROS package and the help here. :)

Happy New Years !

Henry C.

[chrisl8]

That is very concerning. If I were you in would call Parallax and discuss this with them. They have been very responsive to any quality concerns I have brought up.

[henryclever]

Chris,

Parallax sent me a different DHB-10 and it worked immediately. They also sent replacements for the parts that were missing. Your code is all up and working and I can drive the robot! There is a bit of lag driving it with the joystick and the wheels move quite swiftly, but this is something I will tackle and worry about later. Thank you for your help, and happy Martin Luther King Jr. Day!

Henry C.