Spike Prime intermittently stops at beginning of run

[dss0427]

We are using Spike Prime and Pybricks for FLL and we periodically have the robot stop right after starting a run. For example, one of the runs starts with the robot going straight a couple hundred mm. This works fine most of the time, but sometimes, instead of going straight the robot goes slow a few mm, turns to the left, and just stops. But it hasn’t really stopped. If we pick it up and rotate it in or hands to the left or right, the the wheels start spinning. We have several runs and this behavior happens randomly in other runs. One of the runs the robot is supposed to go straight, then turn about 45 degrees to the right. Instead it does the same failure, it goes a short distance, turns left and stops. And again, it we lift the robot and turn it, the wheels spin. As if it was waiting for a turn.

Could there be a memory leak, or memory corruption?
Any suggestions on what to try?

[laurensvalk]

Is the robot perhaps quite heavy, or has the weight primarily off center?

It sounds like the robot is not always able to complete the move near the end.

If you have a spare robot, perhaps you can test the same code on the standard small drive base to confirm.

There are ways to increase the power levels for heavy robots and add a bit more flexibility in completing moves.

This comes up every once in a while, so we should probably add a tutorial.

[dss0427]

The robot is not heavy at all. And, as I said this happens at the very beginning of the run. At the beginning of each run we have the robot go backward for 0.1 seconds so that it is square against the wall. Then it goes forward. The first run it goes forward enough to get out of the circle. That works some of the time. Other times it goes forward a few mm and then makes an abrupt turn to the left and stops. We’ve tried taking out the going back against the wall in the beginning and the problem still happens.

This is intermittent. Everything works fine for multiple runs, but then runs will start to exhibit this behavior. Without changing code, we were merely practicing running the robot in preparation for a competition. Very disconcerting when you push the button for a run and it just stops after moving a very short distance. Problem seems to happen more often over time during our practice meeting. Which is why I suspect a memory issue.

I’ll try to send 2 short videos, one with it going straight like it should and one with the failure we see.

At the end of our meeting last night we tried using our second robot. Over the season it had been used for testing new attachments so that it didn’t interfere with those using the competition robot. But it wasn’t built exactly the same, so we will need to make sure it is the same. Last night it behaved correctly, but as I said the problem seems to be intermittent and seems to be fine and then starts happening more frequently, and we used the backup robot for a short time.

[laurensvalk]

It would be great to see the code that does this.

If you can reduce your code to just those first couple of moves that would be best.

Then we can try to reproduce it and fix it if we can identify the issue.

[BertLindeman]

Best course of action of course is Laurens' advice.

But might it have to do with the battery sitting too loose in the hub.
Hypothese: acceleration moves the battery a bit and sometimes the voltage drops causing the hub to get a bit confused.
You report that later the error occurs more often. Maybe the battery voltage has dropped a bit by then?

Had to report this 😄

Bert

[dss0427]

Here should be enough of the code. When we want to execute the first run we call "Run 1", aka Run_1. The first thing each run does is call "Back Against Wall". That moves backwards 10 mm at a speed of 50. It will wait 200ms as a safe guard against the backing up never completing. Run 1 then moves 340 mm. But, when we run into the situation I described, it doesn't do that move, instead it rotates left about 30 degrees and stops,

async def Run_1():
    global Program_Running
    await wait(1)
    await _2('Change shipping lanes, release quadropus, and raise crusty crab')
    Program_Running = True
    await Back_Against_Wall()
    await Drive_Base.straight(340, Stop.BRAKE)

async def Back_Against_Wall():
    await wait(1)
    Drive_Base.settings(straight_speed=50)
    await multitask(Drive_Base.straight(-10, Stop.BRAKE), wait(200), race=True)
    await Reset_Speed()

[dss0427]

BrickAndSharky.zip

[dss0427]

Here's the code, but it isn't the code or the robot. It seems to be a bad (left) motor. It seems to stop turning. If we have the robot going straight and the one motor isn't spinning, will PyBricks stop? I assume it is doing that because it was unable to correct? Which is fine, just trying to understand what we saw.

[dss0427]

If you look at the code and have comments about it, I'd appreciate it.

[laurensvalk]

Happy to help --- but it would really be useful to try to create a small program that reproduces the problem :)

If you say it happens in just the first couple of moves, try making a program with just those components.

(This is a very useful skill for the team to practice, not just for this issue. It's a good thing to discuss too when judges ask your team about the way they tackled problems.)

Also, if I might ask, what is the benefit of doing the following throughout as opposed to using the comment block?

[laurensvalk]

Saw your note about the left motor after I posted the above --- sorry about that.

I can't say for sure what's wrong with the motor. If it is fine most of the time but misbehaving during one particular command, it could still be code.

Some motors have a bad cable. In that case you should get an error in the output window at the bottom about a device not being connected. Some have more friction than others. To find out, run both at 50% power. This is just power without any corrections. Some difference between motors is expected, so it will veer by some amount, but not take a tight corner.

[dss0427]

We borrowed a hub from a team that hadn't moved on to the next competition. They were a brand new team, brand new coaches. We substituted their hub onto our robot which was having issues, because we assumed it was an issue with the hub. Tried our first run, and it failed. Must be the left motor. It is stopping spinning, causing the robot to turn abruptly to the left. Not a hub problem and certainly not a PyBricks problem.

Is there a way in PyBricks to detect a problem like this? Haven't looked into the documentation, is there one that goes over tracking down issues like this?

I had talked my co-coach into trying PyBricks instead of the spike prime development environment. I've really like it. Seems more accurate than spike prime, and like not needing a my block for acceleration, it is built in. We didn't look at the underlying Python code much, maybe next year we'll do that.

Thanks for all the help.

[dlech]

No date/time support.

There is StopWatch that can be used as a time source. If you create clock = StopWatch() at the start of a program, then clock.time() will be milliseconds since the start of the program.

The hubs don't have a realtime clock though, so it isn't possible to get wall clock time.

[dss0427]

Oh, didn't think about RTC support. But, I think that when someone presses the 'run' button that the current date/time could be set in the running code. Not a problem, just a "nice to have". The kids have added debug prints including how long movements take (so they know about StopWatch(). It would be nice to have the debug prints start with the current date time, so they can be properly ordered. An example of what they currently print, here is their first run's output:

---- 💪 Brick & Rocky 🥊 ----

Hi, Wheels IV!
Waiting for Gyro...
Running!
Selected Run: 1 - Boulderz
Pit Stop Finished: 0.0 Seconds - Total: 0.001 Seconds

Running Run: 1 - Boulderz

• Forge, Who Lived Here, Heavy Lifting, What's on Sale
• Backing Against Wall
• Straight 730mm -0.01° to -1.1° - 2.537 Seconds
• Release the Ore blocks
• Turn 43° -1.1° to 42.79° - 0.568 Seconds
• Straight -20mm 42.87° to 42.75° - 0.364 Seconds
• Revealing Artifacts
• Right Wheel 260° from 1370° to 1624° - 1.013 Seconds
• Straight -110mm -2.65° to -5.9° - 0.843 Seconds
• Turn 95° -5.88° to 89.81° - 1.078 Seconds
• Pushing Ores Into Home
• Straight 210mm 89.86° to 90.85° - 1.138 Seconds
• Turn -35° 90.84° to 53.63° - 0.488 Seconds
• Right Motor -360° from 0° to -358° - 1.139 Seconds
• Straight 150mm 53.44° to 53.19° - 0.963 Seconds
• Left Motor -360° from 0° to -358° - 1.123 Seconds
• 40° Curve 100mm 53.22° to 96.99° - 0.654 Seconds
• Left Motor 360° from -359° to 0° - 1.103 Seconds
  Run 1 Finished - Boulderz: 12.847 Seconds - Total: 12.85 Seconds

Selected Run: 2 - Shopz

[dlech]

There isn't a place to get the date/time from, so that won't be possible.

But if you use the same StopWatch instance everywhere, then 0 is when the program started.

from pybricks.tools import wait, StopWatch

timestamp_timer = StopWatch()

def timestamp() -> str:
    return f"[{timestamp_timer.time() / 1000:.3f}]"

def log(msg: str):
    print(timestamp(), msg)    

log("one")
wait(500)
log("two")

gives:

[0.000] one
[0.500] two

[dss0427]

Thanks. Like I said, I only wanted the date/time so that we could print it at the beginning of our runs, to document when it happened. Not a big deal to not have it.

[dlech]

Oh, totally I missed the point. 🤦 My bad.