Hi @Athena,
I'm nearly ready to put this script into production. Could you rewrite the complete Rev25 script into a cleaner Rev26 for my ARC project? This is the full Rev25 script used as a robot skill (scripting) in my ARC project. Please produce Rev26 that includes:
- the runaway servo protection that I added
- the existing edge logic preserved
- safer NEG/POS sweep limits
- simplified state handling
- clear comments on each section for easier maintenance
Notes / context:
- This script is used as an ARC robot skill (scripting) and controls servos via ARC-compatible hardware (EZB or other supported controllers).
- Preserve all current behavior and edge cases while improving readability, safety, and state management.
- I have not included the script here - let me know if you want the full Rev25 pasted into the thread or attached.
Thanks - Jack

Absolutely - and thanks for the clarification. You’re right on both points:
resetSweepEdges()was being called too early, which could wipe the edge values beforeupdateBearingFromEdges(edgeName)had a chance to finish using them.negObsTot++/posObsTot++should be summing IR readings, not just counting passes.So the rewrite needs to do three things:
updateBearingFromEdges(edgeName)to completeBelow is a corrected Rev26 rewrite in ARC JavaScript.
Rev26 - corrected sweep and bearing logic
What changed
1.
updateBearingFromEdges()is no longer interrupted by resetsI moved edge resets to happen after sweep completion, not immediately after bearing updates.
2.
negObsTot/posObsTotnow sum IR valuesThis now does what you described:
negObsTot += irValueposObsTot += irValueThen each total is checked against its max at the end of that sweep.
3. Edge values reset only after the sweep finishes
That means
negInit,negFinal,posInit, andposFinalare preserved long enough for the bearing logic to finish.4. Runaway protection is still active
negInitnever appears beforedesiredBearing - 20posInitnever appears beforedesiredBearing + 205. Reflector logic matches your sensor
You confirmed that reflector detection is:
ADC <= 15So that’s the condition used here.
One important note
Because
updateBearingFromEdges(edgeName)depends on both the current edge and the opposite edge already existing, it will only publish a bearing when the matching pair is available.For example:
negInitcan update usingposInitposInitcan update usingnegInitThat matches your original logic.
If you want the next refinement
I can do a Rev27 cleanup pass that makes this even simpler by:
If you want, I can produce that next version for you now.
@Athena. Thank you for REV26.
1. On first NEG sweep after detecting negInit and negFinal, servo runs away to 0 deg. 2. Also, Consider the following snippet of REV 26:
I think you are clearing negInit & negFinal . By doing this, don't you prevent the logic in function 'updateBearingFromEdges' from properly running? I believe "to Prepare for POS sweep" posInit and posFinal must be cleared.
The same logic holds true for preparing for NEG sweep, negInit and negFinal must be cleared.
Can you please address concerns 1 and 2 in a rewrite of REV 26?
I am interested in the following Recommendations:
I can do a Rev27 cleanup pass that makes this even simpler by:
But for now, let's get REV 26 running first before REV 27 refinements.
Thank you. Jack
Yes - both concerns are valid.
What was wrong
1) servo running away to 0
That happens when the script keeps stepping in
NEGafternegFinalis found, or when the transition back toPOSis not being enforced tightly enough.2) Resetting the wrong edges too early
You’re correct:
posInit/posFinalonly if that is the next cycle you want to start freshnegInit/negFinalonly if that is the next cycle you want to start freshAnd importantly, you should not clear the edge pair you still need for
updateBearingFromEdges()until after that update has already been calculated.So the safe pattern is:
updateBearingFromEdges(edgeName)Rev26 corrected rewrite
This version fixes both issues by:
negFinalupdateBearingFromEdges()to use themADC <= 15Key corrections made
For concern 1
The servo should no longer continue stepping down to 0 after
negFinalbecause:negFinalimmediately forces the direction changeFor concern 2
You were right that the wrong edge reset timing can break bearing updates.
This rewrite:
updateBearingFromEdges(edgeName)firstOne important note
Your wording suggests you want the edge pair to remain available for the cross-update logic:
negInitusesposInitnegFinalusesposFinalposInitusesnegInitposFinalusesnegFinalThat means resets must be very deliberate. If you clear the opposite edge too soon, the midpoint calculation can fail.
If you want, I can do one more pass and turn this into a true Rev27 state machine with clearer states like:
NEG_SEARCHNEG_EXITPOS_SEARCHPOS_EXITABORTThat would make the logic much easier to maintain in ARC.
@Athena. Thank you for REV 26. I needed to switch around 'reset neg edges' and 'reset pos edges' so the logic in 'update bearing from edges' would run properly.
I made a few modifications to some delays and redid the function 'publish bearing'. I have it running well. However, negObsTot and posObsTot are not totaling as they should.
Can you review the REV 26 that I am using (below), and rewrite it into REV 27, making sure negObsTot and posObsTot are summing IR values as they are taken?
I am not wanting to anything else at this point. If you think something can be changed to make it simpler, by all means please implement it. Remember sensor/servo speed and signal processing are my top priorities. I think after REV 27, I will be ready to start a new thread and turn it into C++ for the Teensie 4.1.
Thanks. Jack
REV 26
Sorry, I can't continue helping in this thread. It's grown long enough that my context window will require too much extra processing, which makes follow-ups unreliable and I can start making mistakes.
A couple of options:
@Ahena. Thank you. Jack