I made a couple posts earlier today and managed to get GroG's attention, and a hearty "welcome back."  He also asked if I had a specific goal or reason for my Processing request.  I'm going to try to answer that here.

MRL has a special place in my heart.  GroG made it easy to try things without writing a lot of code.  Also, in the pre-InMoov days, it seemed I had GroG all to myself.  Houston was an interesting project, and whenever I had an issue, I'd submit a no-worky and in a day or two, there would be a new version that addressed my specific problem.

I have a habit of picking good hardware that turns out to be a bad choice.  Case in point--the Xtion 3d camera is superior to a Kinect in just about every way.  It's smaller and lighter and runs off a USB port without the need for an external power supply.

Then Apple bought up the IP to it and apparently buried it.  You can still find support for it out there, but you can't buy a new one.  Likewise  Odroid is a great line of little SBC's but there aren't many sources for them, and not many people using them.  Also, the specific model that I picked to replace my original SBC is no longer available.  RasPi's are everywhere and the newest one is pretty much plug in compatible to the original, and quite a bit faster besides.  I've heard it's still too slow to run OpenCV, (A problem that the Odroid X2 did not have.) but that could change with the next release--or even the next RasPi software release.

SO, my new project is made of parts that should be easy to source and relatively low cost;  and uses construction techniques that are easy to duplicate.  (Hint--no 3d printer required.)

GroG asked if I had a specific task in mind for Processing.  I can't say that I do, other than that I have a little bit of formal education in it.  (Actually, what I REALLY learned about Processing I got from YouTube videos.)  It's got libraries for vision and language processing, and its code can be compiled into Java runtimes.  Since it can use Java libraries, and output Java code, for the most part I was curious as to how close it already is to MRL.

Anyway, I've been lurking for a long time, and I can see that MRL has been changing in good ways.  GroG has help from real coders now, and the favor of the force behind what is (arguably) the best DIY robot project out there.  Good things are happening and I hope to be a part of it again.

bensonofjohn

9 years 3 months ago

About seven years ago i was involved in a University program writing a book to teach Processing. Back then it certainly had several libraries to simplify the whole graphics side of programming. I haven't looked at it since but I imagine it has grown well with plenty of contributors.

This year i've been running a programming club for a school teaching Python which i found very eay to pick up, though slightly tougher for the kids with enforced indentation rules and strict syntax. Probably a good thing that it teaches them good habits from the start. The biggest lack for me was the graphics side, having to add Pygame to draw to the screen was a shame and increased the complexity very quickly.

You've been on both sides of the fence, and I especially respect comments and insight from people with that sort of perspective.

You might be interested in another direction Processing has been taking:

http://py.processing.org/

Python mode puts Python in the Processing IDE, along with the graphic and media features of Processing.  It might be a good substitute or alternative to Jython, which is a big part of MRL.

 

That had totally missed my radar. I'm going to have to research more into that. I have to start programming club again in a couple of weeks and this could be of great use.

Interesting DWR .. you always have good links ...

Python mode puts Python in the Processing IDE, along with the graphic and media features of Processing.  It might be a good substitute or alternative to Jython, which is a big part of MRL.

Just a slight clarification.  Processing is doing what MRL had done much earlier - They are using Jython - which is a brilliant Python interpreter which runs on a Java VM.  You can see some of the credits looking at Jonathan's Github blog - https://github.com/jdf/processing.py/wiki

I've been impressed with Processings modular design and always keep that design aspect a priority.

Processing's objectives are to the visual arts, and while MRL's mantra is "Creative machine control". Certainly, good visualization will aid in creative machine control.

Processing is really a very large  application now.  Its well designed and modular to some form.  
My first thought is :

  • Should there be a bridge?  This leaves Processing and MRL completely seperate and a software communication bridge (TCP/IP) would be created to have the 2 applications interoperate.  Pros - remote communication possible  Cons - serialization & messaging is more complex than direct access
  • Should Processing have MRL as a "plug in" 
  • Should MRL have Processing as a "Service" 

I flew over Processing plug-in documentation years ago .. maybe its time I look again ...

My first gut feeling is Processing as a Service in MRL .. just like Python :)  or Blender.   Blender is a little different in that its written in C++ and requires a TCP/IP bridge - while Processing & MRL could have much tighter integration...

The thing that really caught my attention about MRL is that it made it really easy to do things that would otherwise have taken a lot of work and code that frankly, I didn't really understand.  Especially with vision and speech.

Processing did pretty much the same thing for me with SimpleOpenNI.

A couple of months into my Processing class, I happened to visit one of my younger nephews and I got him into drawing stick figures with Processing and making them move and bounce around the screen.  I couldn't do that with Python out of the box.

On the other hand, Python is the language behind ROS.

I'm not on a "lets switch over to Processing" crusade.  But when I started to look into Processing a little deeper, I found no less than five machine vision libraries that were installable with just a click.  There's some other good stuff in there too like Firmata to talk to Arduinos and RiTa for natural language processing.

My question was basically "Could it work?"  Which seemed like a good question since I've heard Processing described as "Java with a UI and some graphic stuff."  (Not sure how accurate that is.)  Also, one thing MRL excels at is making a lot of unrelated projects play nice together.  I know that Processing was aimed at artists, but it also led to Wiring, and the Arduino IDE.

Anyway, I've started a dialog on the subject, which was my intent.  And there are lots of people on MRL who are smarter than I am.  The post that got me back into MRL was about changes that should be incorporated.  What to drop and what to lock in.  The direction that MRL takes will be dependent on its users and contributers.

Well said DWR,

I tried Processing a while ago, and I have to say the experience was really quite pleasant. 

Look at this page :

https://processing.org/tutorials

I mean this is how and why Processing shines - A collection of well organized, exteremely well documented tutorials.  With a little time anyone can read, copy, paste and get something rewarding - in the process quite likely they will learn something new !    And with the ability of making clear "cause" ---and---> "effect", it gives others a tool which they can use in implementing thier own ideas ... awesome !

We all have talents to share.  I'm not the sharpest knife in the drawer, but from experience I am relatively good at "Borging" software together...  Speech for example is a huge field, and it can get very complex - I don't pretend I understand more than a superficial level.  And that's what keeps it entertaining too - Robotics potentially incorporates a limitless array of interesting topics like speech, vision, AI.

I'm glad to see you contributing again DWR !  We all will benefit from it.