Problem controlling the motors from the Arlobot Web Interace

[TCIII]

@chrisl8,

Required Info:

SBC: Rpi 4B/4GB OS: Ubuntu 20.04.1 ROS: Noetic Sensors: Four PING sensors: three forward, one back RPLidar: Slamtech A1M8

Steps to reproduce issue:

If I attempt to use the "Remote Control" dropdown panel in the Arlobot web controller to move Arlobot forward, with the mouse pointer, the following occurs:

Expected Response:

When controlled from the "Remote Control" dropdown panel in the Arlobot web controller the robot should continually move forward as long as the mouse cursor is in the center of the white circle inside the light gray circle and has been pushed upwards towards the edge of the light gray circle.

Actual behavior:

Moving the small circle to the top of the large circle using the mouse cursor causes the robot wheels to turn forward for about 5 seconds and then stop. I have to repeatedly keep moving the small circle to the top edge of the large circle to get the robot wheels moving again every time the wheels stop after about 5 seconds.

[TCIII]

chrisl8 commented:

That is strange, and should not happen. I don't think that it is related to the unplugging function or the plugged in status.

If it moves at all, then it is ignoring the plugged in state.

The self-unplug function doesn't restrict movement, it operates on its own, so I do not think that it is related to this issue.

As a debugging operation, if you leave everything going as it is, the web site up and ROS running, and then go to a terminal on the robot's computer and run: ~/catkin_ws/src/ArloBot/scripts/keyboard-teleop.sh then can you drive the robot via keyboard? Or does it do the same thing?

[TCIII]

@chrisl8' ,

The keyboard-teleop.sh scripts works as it should with the robot wheels going forward as long as I held the "i" key down continuously and backwards as long as I held the "," key down continuously. The other keys in the teleop layout functioned as expected.

Observation: The robot wheels will turn slowly backwards if I put my hand within two inches of the front facing center PING sensor and will go slowly forward if I put my hand in front of the rear facing center PING sensor. However, if I put my hand in front of either of the two right and left 60 deg front PING sensors, the wheels do not turn the robot away.

I get the same wheels turning either forward or backwards for ~5 seconds and then stopping whether I use the Arlbot web interface on the robot SBC or from my HP PC.

So it looks like there is an issue with the Arlobot web controller in relation to motion control?

Next step?

[TCIII]

chrisl8 commented:

Yes, as you said, your debugging has proven that everything on the robot itself is working perfectly. There is an issue with the web interface code apparently.

I'm still working on getting my robot working well enough to be able to test that feature. Hopefully this evening I can get it there.

It was working perfectly in October when my robot still had a laptop to run it, so I'm not sure what broke or why.

Having a working example again though will at least help me to work out how to help you debug it.

The only quick ideas I have is to experiment with how you are using the "joystick". You have to hold your mouse in the location. If you move too far, it will snap away. So when you are moving it, it should always show the small dot under your mouse cursor to indicate that it is still operating. That probably isn't helpful, but just in case.

[TCIII]

@chrisl8,

"The only quick ideas I have is to experiment with how you are using the "joystick". You have to hold your mouse in the location. If you move too far, it will snap away. So when you are moving it, it should always show the small dot under your mouse cursor to indicate that it is still operating. That probably isn't helpful, but just in case."

Okay, I gave your suggestion a shot:

Observations:

1) I left clicked on the gray panel and a small white circle appeared under the mouse cursor inside of a larger light gray circle. The Linear Speed displayed 0 2) I moved the small white circle slowly towards the top of the larger gray circle with the mouse cursor. The robot wheels started to move forward and ran for ~5 seconds and then stopped. The Linear Speed displayed 0.26 even when the robot wheels stopped moving. 3) The robot wheels act the same way when I moved the the small white circle slowly towards the bottom edge of the larger gray circle with the mouse cursor. The robot wheels started to move backwards and ran for ~5 seconds and then stopped. The Linear Speed displayed 0.26 even when the robot wheels stopped moving.

Based on the "Linear Speed" display, it seems that ROS still thinks that the wheels are turning even though are aren't?

Is there somewhere I can look in the code to see what is going on?

[chrisl8]

@TCIII Good news! I was able to reproduce the problem. Apparently if you hold the "joystick" steady at any given speed, it just stop sending the command, and then the robot eventually stops.

This is consistent with how things work. All commands must be continuous or the robot stops, but the "joystick" should have triggered a continuous stream.

The key is to wiggle it to keep it moving, i.e. between 0.47 and 0.49 and the constant update will keep it going.

Clearly this is a bug. I'll try to sort it out soon.

I'm not 100% sure where the "fix" needs to be at. It used to work, so I'll start by digging through my updates in the last six months to see if I changed anything.

Probably I added some sort of code somewhere to avoid repeated sending of the same data and that broke it, but I'm really not sure yet.

[chrisl8]

P.S. I'm realizing now that the way I have to drive my robot, I almost never drive it continuously in one direction without making steering connections when using remote control. So it may be that just my actively moving to correct for speed and direction was keeping it working.

Anyway, I'll sort out a fix, but you may find that if you have to guide your robot around obstacles and such, that you don't run into the timeout as much.

[chrisl8]

UPDATE: This never worked. Here is an explanation:

1. The way ROS Twist commands work, they basically "time out" after about 1 second.
2. The Twist inputs are intended to be repeated by the publishing side for as long as the movement is required.
3. As soon as the messages stop, they time out, and the robot stops.
4. The web interface remote control works as a DIRECT ROS Publisher, so it literally sends Twist commands straight to ROS using RoslibJS. This is very reliable, fast, and nice, but it means that there isn't any code in the middle forcing a repeat like there are in tools like the joystick or keyboard teleop codes.

I've used this code for years and never really thought about it, but if I want to run the robot at full speed, with no course correction, I have to basically slide the mouse (or my finger on my smartphone, which I have used to drive this across parking lots to meetings) back and forth slightly as I go to keep a steady stream of data going.

At home, I use Rviz to make maps by setting destinations and then I use the waypoint navigator to have it go to those after saving them, so I rarely use the joystick. When I do though, it is always to navigate into or out of tight situations either because the robot got stuck, or because I just need to park it or move it without picking it up, so it works out fine.

Clearly this isn't ideal though.

Leave this issue open and I'll try to imagine a fix and implement it. For now though, just be aware that this work the same for you as it always has for me.

P.S. I think I have an idea of how to fix this. I'll try to experiment with it this evening or later this week...

[TCIII]

@chrisl8

P.S. I think I have an idea of how to fix this. I'll try to experiment with it this evening or later this week...

Sooner would be better as the wife is bugging me to move the Arlobot off of the dining room table.

[chrisl8]

@TCIII I have posted an update. Run:

bash <(wget -qO- --no-cache -o /dev/null https://raw.githubusercontent.com/chrisl8/ArloBot/noetic/setup-noetic.sh)

again on the robot, and it should pull down the updates and rebuild the website with the changes.

[TCIII]

@chrisl8,

Nice! Thanks for the quick update.

Did you incorporate the updated Slam Toolbox installation too or should I uninstall the Slam Toolbox after your update and use the updated Slam Toolbox installation?

[chrisl8]

I added code to the setup file to perform apt install of the slam tool box and slam toolbox rviz plugins to the system.

If you already installed them, then it doesn't matter, apt install will just see that they are installed along with everything else and keep going.

[TCIII]

@chrisl8,

Installing "apt install ros-noetic-slam-toolbox-rviz" causes issues when quitting rviz. See my post in issue #178.

[TCIII]

@chrisl8,

I ran "bash <(wget -qO- --no-cache -o /dev/null https://raw.githubusercontent.com/chrisl8/ArloBot/noetic/setup-noetic.sh)", rebooted and started ROS on the robot computer.

1) Once ROS was up and running I checked the Telemetry and made sure that there would be no impediment to robot movement. Using the Remote Control dropdown 2) I was able to drive the robot chassis forward, backwards, right and left continuously and smoothly without issue!

Unfortunately when driving the robot chassis from the Arlobot Web Interface on Desktop PC, it is a different story.

1) When using the Arlobot Web Interface Remote Control dropdown panel to drive the robot from the PC, the forward and backwards motion varies from smooth to some ratcheting no matter where the mouse cursor is pointing for forward or backwards motion. 2) When the Arlobot Web Interface is running on the PC, attempting to use the Remote Control on the robot computer results in the same variation from smooth to some ratcheting when going forward and backwards. 3) Shutting down the PC Arlobot Web Interface results in smooth, continuous forward and backward motion of the robot motors when using the robot computer Arlobot Web Interface Remote Control dropdown panel.

Observation:

My Arlobot chassis is up on blocks so there is no physical load on the chassis wheels which could be causing the ratcheting issue. However, why does the ratcheting quit when I turn the PC Arlobot Web Interface off and just use the robot computer Arlobot Web Interface to drive the robot chassis?

[chrisl8]

@TCIII

I think what you are saying is that if the web interface is up and running on any TWO systems, then the movement is not smooth?

If you close the browser entirely on the robot's computer and ONLY run it on the remote computer, is it smooth?

It could be that the two web inputs are essentially fighting with one another. Let me know if that seems to be what is happening.

Thank you.

[TCIII]

@chrisl8,

Is it safe to shutdown the Arlobot Web Interface on the robot computer once the PC Arlobot Web Interface is running without an issue about stopping ROS using the PC Arlobot Web Interface?

[chrisl8]

@TCIII Yes, it is 100% safe to entirely close the browser window on the robot. All of the important code is running in the background on the robot's computer.

If it the web interface is popping up on its own every time the robot starts, edit ~/.arlobot/personalDataForBehavior.json find this line: "launchBrowser": true, and change it to: "launchBrowser": false,

Then it won't launch the browser automatically on the robot. I almost never have it open on the robot itself as I always control it remotely, but it is usually helpful to new users to have it launch locally so that they can see it right away.

[TCIII]

@chrisl8,

Yes, having both Web Interfaces open at the same time was causing the ratcheting. Shutting down the robot computer Arlobot Web Interface after starting the PC Arlobot Web Interface cured the problem.

Now to make a map of a room and have Arlobot follow the map around the room.

[chrisl8]

@TCIII Thanks for sorting out the cause.

Leave this issue open for now and I will work on a fix later. It should be easy enough to reproduce, and it is definitely the kind of annoying bug that I want to clear up.

[chrisl8]

@TCIII This issue is fixed now. You can run

bash <(wget -qO- --no-cache -o /dev/null https://raw.githubusercontent.com/chrisl8/ArloBot/noetic/setup-noetic.sh)

to pull down and build the latest updates.

Reopen this issue if you find that it isn't fixed.

Thank you.