This is something that would have helped me a lot for my obstacle-avoidance project. The traffic light does a good job setting up what a state-machine is, but never touches on the need for gate-* to feed inputs on nodes that control Arduino pins. I still don’t understand why h-bridge needs the PWM pin gated, but not the others. Maybe what I’m looking for is more of a technical documentation than a tutorial…
Adding a servo device that works on state-machines would also be helpful (like the servo-enable I created with an enable pin that does attach/detach, but I don’t think that would be a very good solution for a robot arm that cannot just let the servo free-wheel between changes).
I guess an alternate way of using state-machine might be to have all the nodes with control pins on the main patch and work out some way to change the inputs over time (likely with select-* nodes, but that could get messy fast…). That’s probably more a complicated feed-back loop than a state-machine, though.
Now I’ve got myself wondering how to implement traffic lights for 2 directions…and of course how to add optional left-turn lights… There’s always brute-force with delays for green & yellow and always turn on red light if any other direction has yellow or green, but there should be a cleaner way. Even using state machine and having to add all the red lights for other directions to each yellow & green light seems clumsy.
BTW: the built-in tutorial on 1st startup was very nice. It might be a down-side that it provided enough info that I didn’t bother reading any other introductory documentation and jumped straight to the traffic light example & wondered where to go from there The only introductory thing I’ve found that isn’t in the tutorial is how to pan around the work-space area. Tossing that into the tutorial (or adding scroll bars) might be nice.
I have actually planed a three-part series in “Doing things sequentially”. I have a draft for the second article but refuse to publish it because since I wrote it down, it became obvious that resource sharing in XOD is a clutter at the moment.
Since then I started to think how we could ever solve this, avoid hacks, and make things simple and intuitive. I think I’ve got an idea, but let it brew. I will post the concept to RFC here.
Until we’d add the magick. resource sharing will be painful. I’ll think about an article of the least-possible evil pattern when sharing hardware. Any suggestions are welcomed!
Here is a rough 1st draft for a possible advanced tutorial. I was too lazy to hook up LEDs for the test, so it uses LCD & signal-*-ext to turn on BUILTIN LED to verify 1 LED. These would need removed before tutorial is published. Additional information is needed to describe what is going on. Probably code for left-turn signal should be pulled out & added as a final step so it is easier to explain what it is doing.
I intentionally left it as sort of a meandering walk through of the development process–maybe too much so…
It still doesn’t deal with over-lapping node calls that need gate-* or servos that need some way to detach, but it talks a little more about how to decide what gets encapsulated. Probably that should be more explicitly stated in the comments. Maybe also explicitly comment on how pins are getting initialized (why is 2nd direction already red on 1st cycle?). If any defer-pulse’s that I have are not needed, they should be removed.
Here is an update that incorporates some of my own suggestions above. I haven’t defined the pins & tested yet, so there could be some bugs besides the wording that needs cleaned up. This should be enough to get a discussion going about what should be included. One idea was to skip the traffic-select & signal-select and just note in traffic-select-flat that we can simplify & jump straight to traffic-delay-flat.
At this point, I am assuming that people will go through the existing traffic light tutorial before seeing this, so they will already have some experience and the state-machine background that it provides.
Hmmm…I forgot to point out in my edits why/how details about what I was going to encapsulate into nodes…
To me, it looks like the most value of the project is the way you have gone through to simplify from the initial attempt to the final result. It is sooo simpler.
You’ve created a useful doc in the same form as welcome-to-xod does, i.e. not Markdown text, not a YouTube video, but a guide embedded in XOD. I’m thinking what’s a proper place to publish such stuff?! Maybe a special section in “User Guides”… but they are split by topics, not medium… but if we’ll place a link to the xodball right next to the “Traffic Light Example” it may be confusing how one should “read” it… Maybe we should make a lite web-embedded readonly project viewer… Hmmm…
I’m way too lazy to have even thought of a solution like that…my idea would have been to tell people how to download & start any xodball, then make sure each tutorial auto-loads the 1st page and has instructions for loading the next page. Unless beginners are having trouble getting through the welcome-to-xod tutorial, that should be sufficient.
One thing that would be nice for tutorial-style projects is a good way to open the next patch and close the current patch; preferably from within a comment, or perhaps a special node that can be placed just after the comment but would be ignored if the current patch was downloaded. I’ve had problems with the GUI when I open too many patches and they no longer fit across the top of the screen.
Please let me know if you see any bugs or mis-match between code and comments, or just have suggestions for improving it or making it easier to understand. Sometimes it is hard to remember how a beginner thinks and describe things in a way they can understand.
Should I start another thread to flag as a “look what I did”? Not sure it would be worth having two streams for comments…
I think it’s a good idea. They attract more attention because they give, not ask. To avoid duplication you can leave a link to the new one and then close the current thread (three dots button below a post)
The only introductory thing I’ve found that isn’t in the tutorial is how to pan around the work-space area. Tossing that into the tutorial (or adding scroll bars) might be nice.
Maybe a special section in “User Guides”… but they are split by topics, not medium… but if we’ll place a link to the xodball right next to the “Traffic Light Example” it may be confusing how one should “read” it… Maybe we should make a lite web-embedded readonly project viewer… Hmmm…