Open Geo-Ron opened 3 years ago
Deze array met states in een Task wordt aan het begin gevuld (setNewTask) Wanneer een state klaar is in een task, wordt Result=Success en kan setNewState de volgende staat beginnen. Deze wordt aangeroepen via getNewState.
Bij Result=Failure wordt ActualDistance gevuld, en een rollBack gestart op basis van deze data.
Dus:
Obstacle:
Met het obstacle kan bepaald worden of de linker bumper (bijvoorbeeld) deze ontdekt heeft. Dan kan met een obstacle_read ook gekeken worden of rechts ook een object te vinden is. Afhankelijk van de input kan worden bepaald wat de actie is.
Voorbeeld:
I have spend the last week going through your code and I am really impressed on the motor control with odometry. I do not fully grasp the inner workings of the PID controller and some of the calculations you make, but that will come eventually 😉
I have seen that it has become a really complex state-machine, because of the old Azurit code remains and that you have created a new state for every operation/target. In my opinion this makes everything over-complex and hard to improve.
I am proposing a new/revised way of coding the Ardumower, that I want to contribute to your current code.
I would like to know your point of view on this method and would really like to accomplish this together, instead of creating my own standalone fork of your code. So please reply here and discuss.
Change the way the states are used
My thoughts would be that we use the following items:
In the code it would be wise (to my opinion) to honour the following rules:
My recommendations on the state improvements would be the following
States (these would be the actual action the robot is doing; the outputs)
Statuses (what major job am I doing)
Task (current task/substatus)
This task would consist of a few predefined STATES.
For example, avoid obstacle would be reverse, roll x degrees, circles around it for x meter, roll back to original heading and resume status.
You have to think about the states the other way around.
The used of only technical machine states instead of functional will reduced the amount of code that needs to be maintained because of less duplicate code.
A few examples:
I know you have abandoned the GPS usage, but I would like to use it for a fast_track to go back to station. Only a first drive heading to find the perimeter.
A DEV branch would be a good idea.