search

ClemensElflein / OpenMower

Let's upgrade cheap off-the-shelf robotic mowers to modern, smart RTK GPS based lawn mowing robots!
Other
4.64k stars 274 forks source link

Fix emergency bit confusion #72

Closed Apehaenger closed 5 months ago

Apehaenger commented 1 year ago

Recognized that @kevinmce also had some emergency-bit confusion in his cool #71, like me (during my Stock-CoverUI development).

Tried to clear that up by evaluating the whole chain from Hall-x labels on the PCB, PIN_EMERGENCY_x definitions, up to the emergency logic, with comparing the the actual doc on a 0.9.x OM-MB, and also cross checked PCB Hall- labeling with PIN_EMERGENCY_x definition on the 0.13 schematics. Beside my further tries to make that part some easier to read, I did not changed any emergency bit position, but corrected the (in my point of view) wrong comments.

Because testing take mostly longer than coding, I would like to ask before, what do you think about my adjustements and if you're interested to merge, if it got tested?

ClemensElflein commented 5 months ago

Good idea, AFAICT, this is already part of #80? Should we close this PR then?

Apehaenger commented 5 months ago

No. Only the #defines are in #80 the logic change and the corrected emergency comments are here.

Apehaenger commented 5 months ago

Corrected online. Not validated yet. To late now :-( Will do tomorrow and add a further comment.

Apehaenger commented 5 months ago
  1. Checked once more 0.9.x and 0.13.x schematics as well as PCB drawings
  2. Switched to bitwise emergency processing as it save some if's, assignments as well as simplifies Stock-CoverUI integration
  3. Unfortunately changed processing order of stop, tilt and lift handling with the result that the diff view look somehow confusing
  4. Tested all Hall1-4 inputs and cases (stop, tilt, lift) with a 0.9.x on my table as well as with a Stock-CoverUI. For the latter I couldn't test the Hall Inputs (no cables), but was able to test the Stop buttons