It's really neat to see some FRC code here, lots to be learned from student robotics competitions!
Shameless plug: I work on [PROS](https://github.com/purduesigbots/pros), an open source programming environment for VEX. We've talked about adding coroutine support there, this article is an additional push for getting that done!
Coroutines make robot code easy
81–90 of 127 posts
Re: Coroutines make robot code easy
#82Similar code could be written in C#, with code like IEnumerable MyRobotBrain() { while(drivetrain.getDistanceInches() > -48) { yield drivetrain.arcadeDrive(0.5, 0); } yield shooter.shoot(); }
I seem to recall reading (though quite some time ago so I may be mistaken), that `yield` was developed for use in robotics as part of the CCR (Concurrency and Coordination Runtime), and it's inclusion in C# 2.0 was to support this.
I read the article, but I failed to understand the problem. What's happening when you pause? Why do you need your functions to pause?
The example robot involves taking a deterministic sequence of actions in a fixed order. The state machine is a line. The article seems to be pretty clear that this code is bad:
while(drivetrain.getDistanceInches() > -48)
{
drivetrain.arcadeDrive(0.5, 0);
}
while(drivetrain.getDistanceInches() > -48)
{
yield drivetrain.arcadeDrive(0.5, 0);
}
The tick function is called 50 times per second. Is it constrained to terminate within 0.02 real-time seconds? What if you want to think hard about something?
Re: Coroutines make robot code easy
#83Earlier quoted context omitted.
The people that do not make GUIs but apps with complex behaviours. I don't think there is a difference here. Callbacks are nice and simple. Callbacks calling callbacks calling callbacks calling callbacks (because of one of worst ideas in programming ever, function coloring) stops being simple. Async/await is just a patch over that ugliness for languages that can't do any better easily I agree with all of this, but th…
> I think the way to go is to have a queue of events/inputs and use that because the ordering and debugging is much better and you don't get the same web of jumping to different parts of the execution. If you just have stream of events that need to be decided upon in order you're in a very happy place; complexity strikes when you want to run handlers for them in parallel to cut on latency, and those handles also need…
I'm not sure what point you are making now. The original story is about coroutines somehow making robotic programming easier and the comment I replied to was saying 'callbacks are not natural'.
Re: Coroutines make robot code easy
#84Although the procedural blocking style is definitely a lot easier, you don't need language support for coroutines to do that. They could have implemented this in Java by just having two threads. One manages the robot and the other main thread blocks whilst waiting for commands to execute. The two threads swap messages using a linked blocking queue.
Re: Coroutines make robot code easy
#85I took computer science at school in 1989 because I hated my chemistry teacher in 1988. Never looked back. I really loved the author's call for attention to whether kids are "getting" the concepts being taught and adjust accordingly.
My teacher (Hi Mr Steele if you are still kicking around!!) taught us the algorithms without coding, but instead used playing cards or underwater bubbles or whatever. We had our a-ha moments intellectually before we implemented them in code.
As an aside, our school had just got macs and we spent most of the day playing digitised sound files from Monty Python.
"YOU TIT!"
Re: Coroutines make robot code easy
#86Earlier quoted context omitted.
I seem to recall reading (though quite some time ago so I may be mistaken), that `yield` was developed for use in robotics as part of the CCR (Concurrency and Coordination Runtime), and it's inclusion in C# 2.0 was to support this.
I read the article, but I failed to understand the problem. What's happening when you pause? Why do you need your functions to pause? The example robot involves taking a deterministic sequence of actions in a fixed order. The state machine is a line. The article seems to be pretty clear that this code is bad: while(drivetrain.getDistanceInches() > -48) { drivetrain.arcadeDrive(0.5, 0); } and this code is good: while(…
The problem is more in how you combine that with something else. Consider, you have two "routines", one for "pick up ammo and take a shot" and one for "evade attack". Without a "yield", then your recovery time after an action is the longest chain of actions you have encoded. With the yield, it is the longest of a particular "command" that you have.
Re: Coroutines make robot code easy
#87I don’t understand why doing this with normal Java is difficult. Just have a list of objectives. Each objective is a class. The autonomous loop picks the next objective from the list and each tick, asks if it has finished, if so get the next objective and so on. All the details about the actual commands to complete the objective and checking the state and so on go into the classes. If no more objectives in the list,…
[deleted]
Re: Coroutines make robot code easy
#88"Deep coroutines:" where you can yield from a function called from the coroutine. Lua supports this, but python doesn't (as far as I can tell). Is there a term for this?
To the author: you could make the code even cleaner by moving the yield to within the action functions. Though maybe this won't work as well for parallel actions...
Re: Coroutines make robot code easy
#89So many similarities with game development: central loop, coroutines, character state machine etc.
An autonomous robot is just a NPC in the real world.
Re: Coroutines make robot code easy
#90If you want to make it easy for high schoolers, just don't use java in the first place...
The only officially supported languages for the competition are C++, Java, and LabVIEW. When those are your educational options...you stick with Java. (We've now switched to Lua, integrated with the official C++, but it's a lot more work behind the scenes.)
What's the hardware/OS stack you have for the autonomous part? Can you go wild and use unsupported software as long as it fits in the official hardware?