Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coroutines make robot code easy

bvisness.me

Post reply on HN
Print view View original

41–50 of 127 posts

Re: Coroutines make robot code easy

#41

Post by omnicognate »

lhecker wrote: post #29
mgaunard wrote: post #19

People 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.

> They're equivalent except that asynchronous callbacks is what actually happens [...] Neither stackful nor stackless coroutines work like this practice. The former suspends coroutines by saving and restoring the CPU state (and stack) and the latter compiles down to state machines, as mentioned in the article. Coroutines are functionally not equivalent to callbacks at all.

Which is exactly what happens when you use asynchronous callbacks except that you have to do the storing of state explicitly. Stackless coroutines even typically compile to (or are defined as equivalent to) callback based code.

Re: Coroutines make robot code easy

#43

Post by shadowgovt »

> We were basically creating a crappy programming language out of Java classes.

At least the pedagogy is accurate. From UIs to database accessors, coding modern Java basically is creating a crappy programming language out of Java classes.

Re: Coroutines make robot code easy

#44

Post by Izkata »

The structure of the coroutine version looks very close to what I've been settling towards for my own background code (not robots but a similar "do a sequence of things that may take different amounts of time and rely on external state"). I'm not sure if it has a name so in my head it's been something like "converging towards a 'good' state":

Every tick, inspect the state of the world. Then do the one thing that gets you a single step towards your goal.

At first I wasn't sure the "inspect" part was possible in the robot system, but the Lua code makes it look like it is? If so, the change is basically changing the "while" to "if" and adding additional conditions, maybe with early returns so you don't need a huge stack of conditions.

The "converging" style doesn't use coroutines and is more robust. Let's say, for example, another robot bumps into yours during the grab - the Lua code couldn't adapt, but the "converging" style has that built in since there's no assumed state that can get un-synchronized with the world like with a state machine / coroutine version. It was because of external interactions like that, that I couldn't 100% rely on but were inspectable, that I originally came up with this style.

Re: Coroutines make robot code easy

#45

Post by kachnuv_ocasek »

noobermin wrote: post #15

Ah coroutines, essentially glorified goto. My 10keV take is that dijsktra's paper while probably right about goto back then has cursed us and we are still cursed till this day. Some logical structures map well to just using goto in a series of steps, but because of this allergy to goto, we're stuck where basically jumping into a random place in a function is "novel."

Coroutines/continuations are not “basically jumping into a random place in a function”. It's pausing the execution of a function in a well-defined place with well-defined, understandable semantics for resuming the execution.

Re: Coroutines make robot code easy

#47

Post by shadowgovt »

quantified wrote: post #3

Thankfully a piece that emphasizes that coroutines are functions that pause. Java frameworks like Quasar became focused on other goals besides that basic capability and lost their way (IMHO). Java's not the easiest to pick up in high school unless you really make a big after-school effort. Something like Lua is probably better.

For FIRST robotics in particular, Java and LabView are the most commonly used languages because they are the two for which a robust library is maintained by Worcester Polytechnic Institute for use in the competition.

But I have long been of the opinion that both languages are kind of an ill fit for the application. Python is making some headway and I think it might be a better fit; It has some advantages on legibility, it has an optional static typing system, and it does support coroutines.

Re: Coroutines make robot code easy

#48

Post by shadowgovt »

armitron wrote: post #20
mgaunard wrote: post #19

People 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.

I imagine you would get a lot of blank stares with that POV, at least from folks with working bullshit detectors (like young kids that haven’t been conditioned to “modern” industry practices). I found the article a great example of the kind of crap that passes for programming these days.

In the context of the first robotics competition, teaching the command hierarchy is a good opportunity to teach students what a state machine is... And that can be a good opportunity to talk about what a computer does, because the computer is basically a hardware implementation of a state machine.

But that isn't the kind of lesson that you want to be cramming into the middle of the competition season.

Re: Coroutines make robot code easy

#49

Post by shadowgovt »

dools wrote: post #30

I 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,…

Having taught FRC students to use Java: when you're talking about people with very little experience programming before, the multiple class abstraction is itself an obstacle to accomplishing the goal.

I can't tell you how many times students have gotten frustrated trying to understand why you have to pass arguments into the constructor or, for that matter, Why the constructor is different from other method calls. "But we already said 'drivetrain' in the constructor, and over here in this other class. Why do we have to say m_drivetrain in the class also and do m_drivetrain = drivetrain?" And there isn't actually a better answer than "in other languages that learned from Java's mistakes, you don't. But we happen to be using a language that dates back to when Animaniacs was teaching kids the names all the countries, so some parts are just bad."

Re: Coroutines make robot code easy

#50

Post by scotty79 »

Maybe coroutines might become syntax for general hierarchical finite state machines if we manage to implement serialization of current execution state.

I'd really love to see async/parallel language based on these ideas.

Post reply on HN