Coroutines make robot code easy • Hacker News Board

Re: Coroutines make robot code easy

#101

Post by taberiand » Thu, Jun 22, 2023, 9:03 PM UTC

thaumasiotes wrote: post #82

sparkie wrote: post #18

Earlier 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(…

Only one action can run per robot loop. The first code isn't bad exactly - it just doesn't work for how the robot needs to operate.

Essentially the first code block has the issue mentioned in the article:

    Unfortunately, we can't do this because we need our autonomousPeriodic function to keep ticking. Loops like this will never finish and will cause the robot program to hang. So you can't use loops!

The second code block yields every command back to the robot until the robot is ready for the next command - it's not actually the same as the article code but I think it's better design to return a command to the robot than to run a mutable operation in the brain code, it makes it clearer to the user that it is necessary to let the robot do the work.

The article's point is there are many ways to write the state machine code that makes this possible - and the coroutine approach is the easiest for students to understand. It's also quite clean and practical for real world use too.

Re: Coroutines make robot code easy

#102

Post by bedobi » Thu, Jun 22, 2023, 9:23 PM UTC

esafak wrote: post #96

bedobi wrote: post #79

Earlier quoted context omitted.

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?

To me the whole point of Kotlin is fixing all the things that are wrong with Java lol

But idiomatic Kotlin is still too close to Java, they call it "direct programming style" and it's basically already obsolete

Null safety is great but the way they've implemented it with weird syntax like ? and ?.let is not great, it would have been a lot better to just have a regular Maybe type in the native library from the start. Like sure the nullable type is in some ways functionally equivalent, but it doesn't implement map, flatMap, applicative etc like a Maybe does, and when it behaves like it does, it's mostly kind of by accident, not by any real understanding of those operations (and, fatally, it's completely disconnected from map, flatMap etc on lists etc - those should be interfaces that everything that can be mapped, flatmapped etc on implements, not methods that get hurr durr added here and there, sometimes as a regular method called map, sometimes built into the compiler called let)

They've completely dropped the ball on error handling - they don't even know themselves whether the language or people using it should use sealed classes, exceptions or their shitty Result class (which, again, this is a solved problem, they could have just included Maybe, Either, Try etc in the native library from the start)

Coroutines and structured concurrency are powerful but their API is so extremely confusing and full of footguns that virtually no codebase using them ever uses them correctly to reap the benefits

I could go on - don't get me wrong, I love a lot about Kotlin and it's a massive massive improvement on Java but it's not a great language unless you run it with Arrow and learn to completely sidestep large parts of the language (just like you had to do with Java)

Re: Coroutines make robot code easy

#103

Post by vlovich123 » Thu, Jun 22, 2023, 9:33 PM UTC

jcarrano wrote: post #22

Yes. The callback is not a natural construct (i.e. it does not map well to our intuitive understanding of X is doing something while Y is doing something else). I'm annoyed when coroutines are reserved for use only in high performance, c10k-type of situations. For example, the KJ library's doc says: "Because of this, fibers should not be used just to make code look nice (C++20's co_await, described below, is a better…

> For example, the KJ library's doc says

Just to be clear, the audience for that tour is primarily Cloudflare engineers working on workerd / Workers runtime. Within that context, that's very much correct. The entire codebase is written using asynchronous I/O - synchronous I/O doesn't show up (or if it does, it's in weird parts I've never looked). Fibers are used sparingly in very specific contexts and we have very special code to make it memory efficient at our scale.

Re: Coroutines make robot code easy

#104

Post by ifyalciner » Thu, Jun 22, 2023, 9:53 PM UTC

Coroutines (or the concept of saving context to come back to) is already heavily explored in robotics in recent years. Behaviour Trees [1] approximates what coroutines do in system level controlled ticks mainly to avoid pitfalls of state machines. They are also extensively used in game development too. ROS2 have Nav2[2] package which is based on BTCpp library [3]. Not surprisingly BTCpp library uses boost coroutines to implement some behaviours.

Shameless plug, I have also been developing (weren't planning to advertise yet so no docs or plans for release) a behaviour based C++ library completely built on coroutines [4] to avoid some problems of "Behaviour Tree"s.

[1] https://en.wikipedia.org/wiki/Behavior_tree_(artificial_inte... [2] https://en.wikipedia.org/wiki/Behavior_tree_(artificial_inte... [3] https://github.com/BehaviorTree/BehaviorTree.CPP [4] https://gitlab.com/ifyalciner/ferguson

Re: Coroutines make robot code easy

#105

Post by josephg » Thu, Jun 22, 2023, 9:55 PM UTC

ifyalciner wrote: post #104

Coroutines (or the concept of saving context to come back to) is already heavily explored in robotics in recent years. Behaviour Trees [1] approximates what coroutines do in system level controlled ticks mainly to avoid pitfalls of state machines. They are also extensively used in game development too. ROS2 have Nav2[2] package which is based on BTCpp library [3]. Not surprisingly BTCpp library uses boost coroutines…

Given your expertise, why use behaviour trees when coroutines are available? What value do they provide in languages like javascript where generators work well?

Re: Coroutines make robot code easy

#106

Post by mgaunard » Thu, Jun 22, 2023, 10:02 PM UTC

cturner wrote: post #80

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.

The coroutine approach shines for complex business-logic. Consider this example algorithm, of several async steps, 1. Download a file into memory 2. Email a link to a review web page. 3. Wait for the user to review. 4. Upload the file to a partner. 5. Update a database. You could implement this as callbacks. Callback from each step leads to the next being triggered. Downside - your business logic is spread across all…

Just use lambdas, that makes the sequence local.

Re: Coroutines make robot code easy

#107

Post by mgaunard » Thu, Jun 22, 2023, 10:03 PM UTC

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.

Stackless coroutines are literally the same thing.

Stackful coroutines are just a poor man's threads.

Re: Coroutines make robot code easy

#108

Post by mgaunard » Thu, Jun 22, 2023, 10:06 PM UTC

pie_flavor wrote: post #95

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.

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 b…

Closure state is a serious matter, especially if you're not in a garbage-collected language.

Re: Coroutines make robot code easy

#109

Post by ifyalciner » Thu, Jun 22, 2023, 10:14 PM UTC

josephg wrote: post #105

ifyalciner wrote: post #104

Coroutines (or the concept of saving context to come back to) is already heavily explored in robotics in recent years. Behaviour Trees [1] approximates what coroutines do in system level controlled ticks mainly to avoid pitfalls of state machines. They are also extensively used in game development too. ROS2 have Nav2[2] package which is based on BTCpp library [3]. Not surprisingly BTCpp library uses boost coroutines…

Given your expertise, why use behaviour trees when coroutines are available? What value do they provide in languages like javascript where generators work well?

Behaviour Trees are a bit more than that. They also effect/advice how you structure your project (not component based but behaviour based: exp. you don't have "controller" component in your architecture to handle all locomation but "go_to_pose" or "turn_around" behaviour) plus there are tooling provided around those architectures.

Design of Behaviour Trees were not an answer to lack of coroutines/generators (although they were missing from C++ standards until C++20) but an alternative to state machines.

Although I agree that "tick" based BT implementation is outdated and should completely be replaced by coroutines and mandatory yields (thats what I did in my implementation). There is still value in behaviour based architectures in robotics. They make building complex/reactive behaviours much easier than component based ones.

Re: Coroutines make robot code easy

#110

Post by 62951413 » Thu, Jun 22, 2023, 10:22 PM UTC

rootlocus wrote: post #4

greatgib wrote: post #2

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

Don't get me wrong, I miss Turbo Vision-based UIs and an IDE that fits onto a single floppy disk. But the JVM is a professional tool to begin with. So if you cannot start with a toy such as golang or python at least go with Kotlin.

Borland Pascal already had reasonable static types, classes, pointers, modules with a public API, and blinding compilation speed in the early 90s. All the basic building blocks to grok. Golang seems to be the closest modern-day approximation.