Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch mow motor direction less frequently #71

Closed
wants to merge 1 commit into from

Conversation

olliewalsh
Copy link
Collaborator

Rapid changes in mow direction can cause voltage spikes. Do this less frequently.
I'm assuming the point of this is just to distribute wear on the blade edges so doesn't need to be done that often, just needs to average out over a number of weeks.

Rapid changes in mow direction can cause voltage spikes.
Do this less frequently.
I'm assuming the point of this is just to distribute wear on the blade edges
so doesn't need to be done that often, just needs to average out over a
number of weeks.
@Apehaenger
Copy link
Collaborator

This PR isn't fully clear to me.
The current implementation does not do any rapid direction change.
The mow direction get decided once the mow-motor start and wouldn't change during the whole mow period till it get stopped. If it get started again, i.e. due to area change, the direction get diced again.

The "pseudo" randomization is simply based on the second when the mow-motor get started, and not every second.
I currently can't see where the benefit is:

  1. if the blades get used one time in one direction and the next time (probably) in the other direction, or
  2. if the blades get used multiple times in one direction and the next time (probably) multiple times in the other direction.

Furthermore I see another drawback:
Once we've a timer for automatic starts integrated (and some of us already have this via HomeAutomatization), the mow direction randomization might be never happen if you shift the seconds 12 times to the right?!

@olliewalsh
Copy link
Collaborator Author

GPS timeout stops and starts the mow motor

@olliewalsh
Copy link
Collaborator Author

Probably can just randomly choose the direction when starting the mow area

@Apehaenger
Copy link
Collaborator

What do you worry about? The voltage spike which could happen if: GPS-Timeout occurs -> Motor goes off, but GPS-Fix happen again exactly GPS-Wait time before, so that Motor get immediately started again? (and probably in opposite direction)
For such a lucky punch, would maybe better and easier to implement a (2?s) timeout which must happen before a mow-motor-restart?!

@olliewalsh
Copy link
Collaborator Author

gps_wait_timeout only applies to undocking I think

@olliewalsh olliewalsh marked this pull request as draft October 27, 2023 22:52
@olliewalsh
Copy link
Collaborator Author

Draft for now, will run more testing of the voltage spikes issue

@ClemensElflein
Copy link
Owner

I agree with @Apehaenger on this one, since the time is only used to "randomize" whenever the motor state changes, it should not make a difference at all. To my understanding, we could also use milliseconds here or a real random value instead of seconds without really changing the behavior of it.

@olliewalsh
Copy link
Collaborator Author

Issue this was trying to address is if GPS is flapping the mow motor is stopped and started very frequently, basically performing a full direction reversal. This builds up a lot of charge in the caps and can trigger an over-voltage error.

I was probably running with a low gps timeout thou to force this though. If we just set to gps timeout minimum to a few seconds, maybe 5s, then it shouldn't be as much of an problem.

The change itself just sets the direction on the 2^12th bit (so switches at most once every 4096 seconds), then the frequency setMowerEnabled is called doesn't matter. How about using 2^6th seconds instead instead to switch at most once every 64s?

@ClemensElflein
Copy link
Owner

Yes, with a short GPS timeout it can indeed be a problem.

The issue I see with increasing the time is that since we are using the wall time, any person who is scheduling the mow using home-assistant will always get the same mowing direction: Since undocking and GPS will add some randomness in the second-range it will probably be random with the current implementation. If we do it on hourly or minute basis, then I think for people with schedules it will effectively disable the mowing direction randomness.

Probably the "correct" thing to do would be to randomize on the transition from Idle to Undocking instead of in the enable mower method.

@Apehaenger
Copy link
Collaborator

I'm sorry, but I can't follow your doubts.
If my mower get a mow-motor-stop signal, it is at 0 rpm within one second.
Unsure if your doubts can be triggered in real even with a gps timeout of 1 second.
However, if I'm wrong or ignorant, wouldn't shifting the seconds only >>2 (or 3) times solve both doubts?

@ClemensElflein
Copy link
Owner

Shifting more won't fix ow's issue, even if we shift to one hour. It will only make it less frequent.

Imagine we divide so that the direction only changes each hour and the motor gets stopped at 00:59:59 and then re-enabled at 01:00:00, it will see a rapid direction change (assuming it is still spinning in one direction).

@olliewalsh
Copy link
Collaborator Author

Adding the missing caps seems to have resolved the issue at the hardware level anyway so fine with leaving this as is, at least for now

@ClemensElflein
Copy link
Owner

I'm still leaving this open for now, so that we can move the randomization to whenever the mowing starts instead of whenever the motor state is changed at some point. I think this makes it absolute sure that the direction is randomized and we don't do it too often.

@olliewalsh olliewalsh closed this May 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants