Kivy for Industrial OEM

[Eric Nutsch]

I am considering using Kivy for an HMI (human machine interface) application and have two large questions that I think other original equipment manufacturers would appreciate knowing as well:

1. What embedded Linux hardware platforms does Kivy work on? I dont know enough about OpenGL, compilers, kernels, and processor architectures to know what platforms fall under the umbrella of the primary linux releases? I know that the developers had to port to Raspberry Pi, but since I am not a Computer Science major I dont know where that line is drawn. Debian on Beagle bone black is of primary interest, but here are some more I am curious about; UDOO, MinnowBoard, OpenPhoenux, ARM processors, PIC32 processors, embedded Atom processors.

2. Are any of the developers or the Kivy organization for hire? Obviously the company prefers that I handle everything on this project by myself, but I have done work in the opensource world before and in tough situations it is good to know what the options are.

Thanks!  Eric

[Mathieu Virbel]

Hi Eric,

First of all, i'm glad you're seeing a real interest of using Kivy for OEM. I'm sure there is things to enhance to fit the industrial tests, qualification and process, still, this is exciting!

1. There is multiple points to look at.

1.1 GPU / Initialization: Theorically, you need a platform that supports OpenGL ES 2. This is the absolute minimum required. However, only Raspberry Pi is partially supported. On Desktop, Windows and OpenGL are initialized via underlaying libraries (mostly pygame). On Android, the Java bootstrap do the job. On iOS, SDL2 does it. On Raspberry Pi, we used partially a library for doing it, but this is specific for Rpi. Means, for any others platform, we are missing some bits to be able to create a windows + GLES2 context.

1.2: IO: My experience with Rpi is mitigated. When i was with Thomas in Pycon, and when we first see the Monkey 3D running on it, or the showcase, this was incredible. GPU is insanely fast. BUT, the loading is SLOW. Very slow. We were too focus on the GPU and graphics performance that we never really did any work on optimizing the code for reducing IO. We import a lot of stuff / python libraries, read and interpret a lot of stuff (kv language). The CPU itself suck, Python execution require a good CPU. So basically, the initial loading is slow due to IO (it's not like reading a big file, it's reading lot of tiny python file). The execution of your app might be slowed down if you didn't precached few part of the UI, cause of the slow CPU. But, the RAM on Rpi is limited, so you don't have real power of execution here too.

1.3: Many road to explore and improve: When i wrote an app for mobile, the assets management is always time consuming. Even if you deal with couple of png/jpeg, atlases is not the only way to go. On Android, it's preferable to convert thoses assets to ETC1 when possible, or PVR for iOS. Both have different requirements. None of them are supported on Desktop Computer. We have few tools to compress assets, but it need analysis and good Application architecture.

1.4: SDL2 is currently in a branch, and one of our GSOC student is working to make it as a default windows provider. It should come with few others improvements as well in the execution. Stay tuned.

-> So to be honest about which hardware, it is difficult to answer, and need testing. It wont work without at least a little window provider coded for it. Or go Raspberry Pi.

2. I can be hired, but it really depend of the job content and $$. Feel free to contact me at m...@meltingrocks.com. I known that Thomas Hansen (from fresklabs.com) could be contracted as well if he has time :) I'm sure there is others dev available as well.

Regards,

Mathieu

[ZenCODE]

Hi Eric

To second what Tito has said, I think you will find many willing Kivy developers here. Personally, although I would love to do something like this, personal circumstances prevent a committed response. And, quite frankly, my skills are limited to certain areas and I would not want to pretend otherwise.

Essentially, if you monitor the kivy forum, I think you can see there are many skilled people out there willing to help. If you run into unsolvable issues, perhaps creating a bounty on a defined issue is the way to go? Not sure. Just wanted to add some enthusiasm and options to the response :-)

Peace out

[Amirouche Boubekki]

On Tuesday, May 13, 2014 1:27:01 AM UTC+2, Eric Nutsch wrote:

I am considering using Kivy for an HMI (human machine interface) application and have two large questions that I think other original equipment manufacturers would appreciate knowing as well:

1. What embedded Linux hardware platforms does Kivy work on? I dont know enough about OpenGL, compilers, kernels, and processor architectures to know what platforms fall under the umbrella of the primary linux releases? I know that the developers had to port to Raspberry Pi, but since I am not a Computer Science major I dont know where that line is drawn. Debian on Beagle bone black is of primary interest, but here are some more I am curious about; UDOO, MinnowBoard, OpenPhoenux, ARM processors, PIC32 processors, embedded Atom processors.

You seem to mix SOC ie. mini-mini-personal computers like raspberry and other stuff it seems. ARM is a processor, raspberry use an ARM. it doesn't mean that Kivy will run on every ARM SOC out of the box.

From my limited experience:

- Python can run and is powers software running SOC kind hardwares, depending on many thing the experience can be different. Like is the UI stack optimized somehow for the particular SOC. This doesn't necessarly mean at Kivy level... If the application is a slideshow it will be ok, but a lot of animation can be of some trouble.

- Raspberry is an old hardware compared to what is used nowdays in Europe, America and most probably Japan set-top boxes. But to get a similar cost per-box with recent hardware you will need *big* numbers.

- If there is no mainstream distribution (debian and whatnot) running on it, it will a big job to get things together just to be able to run Kivy. Not talking about fine tuning.

- If there is no open source drivers for the ui stack in particular, even more troubles. For instance, until recently Raspberry graphic drivers were closed source. That's the primary reason why raspberry was "special" compared to classic workstation for which drivers (open source or not) are well integrated into the linux stack.

OpenElec is said to have better tuning than raspabian.

The fact that MediaCenter application written in C++ run smoothly on Raspabian, makes me think that it is possible to get something similar done in Kivy. But I don't know how involving it is (cf. Mathieu answer).

Also dev setup is always slower than production setup.

If you can contact SOC manufacturer directly (you need big numbers) they may provide you kind of ready-to-go linux stack with documentation and stuff. A lot a of manufacturers integrate their drivers with Linux stack for obvious reasons. Texas Instrument for instance provide integration with GSTreamer, probably other provide integration with mesa and the Linux UI stack in particular so that you can "just drop" you kivy app in the provided linux distribution.

Regards,


Amirouche

[Eric Nutsch]

Thanks guys! Very helpful stuff. So if ive got it straight; I am looking for a preconfigured android system or a system that supports a minimum of OpenGL EX 2, is non-SoC, and is either x86 or x86-64 architecture.

@Mathieu   Yeah the Rpi is a little under powered for an industrial application; the long term availability and large community are the main appeal. The application will not be very graphics intensive, but it is bad practice to operate at the maximum capacity of your hardware. One of the big appeals of kivy is that there are no foreseeable software limitations (unlike all the off-the-shelf HMIs). I will initially pursue the kivy via the android tablet route, since that gives us the highest degree of hardware independence at the moment and appears to currently be the primary direction of the kivy community. The only downside there is having to dance between python and java to control the low level stuff.  My manager wants me to look at using 100% Java and skipping python/kivy all together, but that’s a different post.

@Amirouche thanks for the system on chip vocabulary word. Yeah, I just know enough to get into trouble. I looks like if I go the embedded python route I better keep away from SoC (except on a preconfigured android platform) until that market standardizes.

A “standard” fanless x86 pc still has appeal because it can operate in 100% python. It also has much better access to I/O hardware and drivers than an android device. Also, it would feel better to be on Debian instead of on an OS that is controlled by a single rich corporation.

My drive for going kivy fyi; Most large equipment OEMs in the United States (that aren’t rich enough to make their own computers from scratch) use PLCs for equipment control due to the availability and support. While PLCs are great for process automation they are a nightmare for OEMs. PLCs have expensive software with DRM, expensive antique hardware, absence of a true high level programming language, don’t integrate with ERP systems, and a bad habit of spreading the smarts across too many devices. We hope to find a development path that lets us avoid PLCs and other proprietary control systems. Kivy and python look to be a good combination that can easily be competently programmed by an engineer with moderate programming experience, yet still have a lot of power and flexibility.

Keep up the good work on the development guys; I will be sure to post back here with any hardware that I test.

Thanks! Eric

[Ben Rousch]

I would be wary of standardizing on an Android device if your product is supposed to have longevity. Industrial devices often expect to be used for a decade, sometimes 2 or 3, without significant software changes. Now think of the state of Android 10 years ago (it didn't exist) and where it will be 10 years from now. That's going to be a difficult thing to keep up to date, especially if you can't get the original devices any more.

I would lean towards a low powered x86 or AMD64 system running Linux, probably something with an Atom CPU.

--
You received this message because you are subscribed to the Google Groups "Kivy users support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
 Ben Rousch
   bro...@gmail.com
   http://clusterbleep.net/

[Eric Nutsch]

Thanks Ben;

Yeah, hardware dependence is a problem either direction. I agree x86_64 does look the best, but I dont know what GPUs or touch screen monitors are supported; that leaves me with guess and check (but maybe the odds are good?).  Im a long way from having a completed system; I will likely port my project to both before I am done and re-evaluate. My current thought is that hardware changes are less of a problem if you have a community helping you trail blase that platform; and currently that platform appears to be native android hardware.

Two year hardware availability is a must. Long life products are great, but are very expensive(since the mfg covers that risk and inventory), the hardware is always outdated, and realistically the end of life is still not 100% predictable(dropped product line, mergers, out of business, etc). Fortunately unlike industrial process companies, that intend to never rewrite their software, OEMs tend to update their software annually. Though the products have a 20+year lifespan, the back compatibility will be handled in the software.

Looking at hardware some more; I suppose that SoC isnt *necessarily* a problem. By putting everything on one silicon wafer doesnt necessarily require deviation from the standard architecture, but its definitely a possibility. It seems that a lot of SoC boards are more catered to industry with long life capacitors and high temperature operation; so minus the whole compatibility issue they look like the way to go. 

More specifically: Do you guys think this board will run kivy under debian/ubuntu:  http://www.asus.com/Motherboards/J1900IC/

Thanks! Eric

[Ben Rousch]

The specs for that board mention DirectX support, but not do not mention OpenGL. Kivy requires OpenGL ES 2 support in the GPU and drivers, so you would have to find out more about the board's graphics capabilities.

[Eric Nutsch]

I looked up the J1900 intel processor and it says the GPU supports; "DirectX 11, OpenGL 4.0, and OpenCL 1.1. On Android, Silvermont graphics is OpenGL ES 3.0 certified."

http://en.wikipedia.org/wiki/Silvermont#Technology

So it supports OpenGL 4.0, but it also states; "Silvermont is the first Atom processor to feature an out-of-order architecture." It says it runs windows 8 but out-of-order architecture doesnt sound promising.... Thoughts?

[Bill Janssen]

Amazon's Fire TV is a $100 fanless "preconfigured Android system" which is pretty darn fast.  Only one USB port for output, though; PLCs tend to need and use lots of I/O, and usually some EMI shielding.

Bill

[Amirouche Boubekki]

2014-06-03 1:09 GMT+02:00 Eric Nutsch <ericn...@gmail.com>:

I looked up the J1900 intel processor and it says the GPU supports; "DirectX 11, OpenGL 4.0, and OpenCL 1.1. On Android, Silvermont graphics is OpenGL ES 3.0 certified."

http://en.wikipedia.org/wiki/Silvermont#Technology

So it supports OpenGL 4.0, but it also states; "Silvermont is the first Atom processor to feature an out-of-order architecture." It says it runs windows 8 but out-of-order architecture doesnt sound promising.... Thoughts?

I think you will have more chance to know whether this is doable by checking whether a gentoo or debian or something is running on it. I can't find anything useful with one search page results about your particuar hardware. Even if it's not on the open web, it might still be possible. It's a competitive area... http://www.emdebian.org/ can be a good place to start. Even if they don't use Kivy, they might have similar experience.

[Eric Nutsch]

@Amirouche
Here is an instance of Ubuntu14.04 on the J1900 intel processor:
http://openbenchmarking.org/result/1406072-PL-1406072KH27

No documentation on the specific ASUS board, but the ASRock in the benchmark might not be bad either.

http://www.newegg.com/Product/Product.aspx?Item=N82E16813157497

http://www.newegg.com/Product/Product.aspx?Item=N82E16813132100

But yeah its all speculation till I actually try it. Thanks for the input! Its good to see other peoples logic steps in vetting linux/kivy hardware.

@Bill
Amazon's Fire TV would be a good one to keep an eye on. Its basically the tablet route with an external touch screen. Probably a little more difficult than the tablet as getting a touch screen input that plays nice with it may be difficult; but maybe not. Ill put it on the idea list; Thanks!

[Rufus Smith]

This is a rather old posting, but I found it via Google, because I have recently become interesting in using Kivy and Raspberry Pi for machine HMI.  How did you make out with this, Eric?

Galil Motion Controls has an entire app note on Raspberry Pi HMI: http://www.galilmc.com/download/application-note/note5530.pdf

which is what got me interested in kivy in the first place.  (Until now, all my GUI in python was done with wxPython.)

I'm also interested in finding out if there are any free widget libraries with kivy-compatible graphics (knobs, buttons, switches, etc) for HMI

[Eric Nutsch]

Rufus,

The company I was working for at the time decided to go the android tablet route. I used the kivy java emulator Buildozer to generate the app. There was lots of work to make the tablet behave like an appliance, but we did manage to get it to work. The biggest downside was the very long toolchain to get to the io. Kivy>Android(java)>bluetooth>buletooth shield> arduino> canbus shield> rexroth plc

https://kivy.org/docs/guide/packaging-android.html

A much simpler and manageable tool chain would be an industrial computer or RPi with python and its io library. I have a back burnered project to automate a pottery kiln with a kivy HMI. I bought this screen and an RPi 3. I built an enclosure and tested kivy on it but that is as far as i got:

https://www.element14.com/community/docs/DOC-78156/l/raspberry-pi-7-touchscreen-display

Kivy and web interfaces are definitely the future of HMIs. And industrial computers are definitely the future of machine control. People think PLCs are more reliable because they cost a lot, but the market will eventually come around. Good luck and be sure to post progress you make!

-- 
Eric Nutsch

--
You received this message because you are subscribed to a topic in the Google Groups "Kivy users support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kivy-users/pIWI0rL03XU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kivy-users+unsubscribe@googlegroups.com.

[qua non]

https://github.com/kivy-garden/garden.knob 

--
You received this message because you are subscribed to the Google Groups "Kivy users support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+unsubscribe@googlegroups.com.

[Roger Morrell]

I've used Kivy on PC based applications and was interested in doing the same on a Beaglebone Black or RPi.  I see that someone has done RPi and in looking at BBB I think the key parts are there including OpenGL but am not 100% sure .  I liked the BBB better but think as the RPi has a bigger market share it might be safer.