I agree, the shift from Java's state machines or "command" system to Lua's coroutines does seem to make the code more intuitive and readable for beginners . Lua's in-built coroutine functionality can be a game-changer for FIRST teams dealing with the complexity of autonomous code 1. It would be fascinating to see how this technique could be applied to other areas of programming where tasks need to be paused and resumed. It's a testament to the versatility of coroutines.
Coroutines make robot code easy
91–100 of 127 posts
Re: Coroutines make robot code easy
#92"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...
In practice we actually do; I had to simplify for the article. We have a few utilities like a `runUntilDone` that make simple sequences easier to write. Example: https://github.com/frc-2175/2023RobotCode/blob/main/src/lua/...
I suppose we could make more utilities for running coroutines "in parallel", but I haven't really felt the need. At that point we usually have to worry about exit conditions and it feels natural to just write a loop.
Re: Coroutines make robot code easy
#93"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...
For Python generators, you can yield from called functions by using yield from as in this (quick, not stellar) example:
def first():
yield 1
yield from second()
yield 4
def second():
yield 2
yield 3
print(list(first())) # collects all the results and prints them
# Output: [1, 2, 3, 4]
def something():
yield from something_else()
def something_else():
return [1,2,3,4]Re: Coroutines make robot code easy
#94Earlier quoted context omitted.
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?
We can use whatever software we want as long as we use the specified hardware (the NI roboRIO), FIRST's latest firmware, and comply with the match system and safety systems that enable and disable the bot at different times. Many teams have been using a community Python alternative called RobotPy for a long time despite it not being officially supported and FIRST had no problem with it.
Re: Coroutines make robot code easy
#95People always say that coroutines make code easier to understand, but I've always found normal asynchronous code with callbacks much easier to understand. They're equivalent except that asynchronous callbacks is what actually happens and you have clear control and visibility on how control flow moves.
Callbacks are no more 'what actually happens' than coroutines are; what actually happens involves a lot of jumping to memory addresses, and closure state is just as much a compiler invention as async/await. Blocking-style code, by comparison, is how we actually think about the business logic; language features that abstract over callback hell to let you write it make code inherently more clear. People always say it because it's true.
Re: Coroutines make robot code easy
#96Earlier quoted context omitted.
We learned borland pascal and borland c in high school. Java is perfectly fine.
I went to a university where Java was the main language for most of the basic programming courses I've been making a living coding in Java for 10+ years I'm a strong believer in types etc etc I still don't think Java is a great language to teach programming lol too much pointless boilerplate and abstraction to achieve the simplest things lots of footguns and objectively bad standard practices built into the language…
What's Kotlin's massive flaw?
Re: Coroutines make robot code easy
#97Oddly, the kids I mentored in FIRST loved the command/subsystem framework. I kept trying to convince them to do some procedural code to make things simpler (they had little experience coding, even for high school robotics kids), but command/subsystem was their comfort zone and they didn't want to leave it.
It makes sense for students that can make the logical leap that "things the robot can do" are objects too (which is only a tiny step from the nicely-recursive "code can just be an object").
... but not everybody is ready for that step.
Re: Coroutines make robot code easy
#98Earlier quoted context omitted.
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?
The largest constraint on this (in the context of the FIRST competition) is that community matters at least as much as technology.
If you're using Java (or C++ or LabVIEW, to a lesser extent), you at least have a hope of posting to a forum and going "Hey, we think our robot should be doing X and it's doing Y, here's our code, any insights?"
If you use and your own custom bindings, you're on your own.
Re: Coroutines make robot code easy
#99If you want to make it easy for high schoolers, just don't use java in the first place...
We learned borland pascal and borland c in high school. Java is perfectly fine.
I learned assembly in high school, and programmed my first FRC machine in NBASIC (a variant of BASIC built specifically for the robot controller back in the day that, among its other delightful quirks, had if statements that were only allowed to be followed by a label and no else clause).
Java is "fine" in the sense that NBASIC was "fine." There's definite room for improvement in matching the abstraction to the problem domain.
Re: Coroutines make robot code easy
#100Earlier quoted context omitted.
We learned borland pascal and borland c in high school. Java is perfectly fine.
I went to a university where Java was the main language for most of the basic programming courses I've been making a living coding in Java for 10+ years I'm a strong believer in types etc etc I still don't think Java is a great language to teach programming lol too much pointless boilerplate and abstraction to achieve the simplest things lots of footguns and objectively bad standard practices built into the language…
I've written enough Java at this point to think of it as the assembly of OOP languages.
You can write code in it, but in industry almost everything I see is basically a DSL built out of annotations that tries as hard as it can to not involve writing actual Java.
When more of your application is annotations than lines of Java code, the language is probably a bad fit for the problem domain.