Welcome new user! You can search existing questions and answers without registering, but please register to post new questions and receive answers.

Which python version do you want?

0 votes
As we start to work on python support, which one would you all prefer? I am guessing python3, is that correct?

We are now first baking python support into the OpenCV build.
asked May 19 in Programmer Questions by JeVois (10,550 points)

3 Answers

+2 votes
One vote for 3 here. Anything that helps wean myself and others off 2.7 is worthwhile.
answered May 20 by pelrun (2,310 points)
0 votes
+1 Pelrun.

One of the consequence of python support will make uncessary to completely rebuild a jevois image at each modification, am I right ? Just to push .py on jevois ?

This led to my other post on the possibility to edit files through Usb or even remotely via serial port : this would give a more fluent process on modifing/testing modules.

But in first approach just have python extension would be great !
answered May 20 by stilgar (350 points)
Actually you don't need to rebuild the jevois image for new/updated modules either. Just stick them into JEVOIS:/modules (or a .jvpkg version into the root) and restart.

But yes, that'll also be true for any python-based modules.

As for editing the sd card contents over the wire... well, you generally should be doing most of your development natively on your PC and webcam before sending it over to the module. That said, I've made a few attempts to add a network device alongside the video and serial devices but haven't gotten a packet through successfully yet.
And it just occurred to me we can go simpler than a network device. Add the lrzsz package to the image, then add a command to jevois-daemon that runs rz, which is a ZMODEM receive tool. Then you can upload a file over the serial link using sz, e.g. a .jvpkg file.
the python support will allow you to write new modules in python using OpenCV, basically the kinds of things python opencv people do. Something like this: http://docs.opencv.org/3.0-beta/doc/py_tutorials/py_tutorials.html
so instead of a cross-compiled mymodule.so file on your SD you will just have mymodule.py and you can edit it.

now for editing through USB, we do have already two free bulk endpoints that remain in our USB driver so we are going to try to add a mass storage gadget function to JeVois. The doc warns about possible file corruption: in principle you should completely stop all access of the JeVois CPU to the disk while it is being accessed over USB. This is because of many different caching layers that can cause inconsistencies between the JeVois CPU modifying some file and you modifying it too over USB. In practice, for the JEVOIS partition on the SD, only a few modules do write to it in /jevois/data/... so if you are just careful to not mess with those files then you should be ok. Hence our plan is to just export that partition over USB, the OS partition will be reserved for access by the JeVois CPU only.
If you're going to attempt to implement file system access, ignore the mass storage gadget and implement MTP, which is specifically intended for this use case. It's actually part of the Android gadget extensions, which are included in the buildroot.

I'd still prefer a network connection of some sort (even if it's as hacky as adding a second serial port to run PPP over or a getty you can run slirp in... actually I might try out the second.) That has the added benefit of being able to run gdb to debug modules running on the unit, for the inevitable case when it works fine on the host but not on the platform.
MTP unfortunately is not an option because it requires 3 endpoints and we only have 2 left. But we now have USB mass_storage working and we can browse the files on the microSD inside JeVois while streaming video at the same time. Coming soon in JeVois 1.1. It is quite cool, just drag new pictures into the image folder of the object detection module, switch to the video mode for that module, and you can recognize those new things.

We tried to add a second serial port today but that requires a whole new 3 endpoints, the hardware only supports 8, so currently we have: 1 for ep0, 2 for camera, 3 for serial, 2 for mass storage.

For gdb, an additional complication is that the camera gadget requires some userland code before it can get activated. So you can't get the serial-over-USB going, as it is also baked into the same (composite) gadget, until jevois-daemon has started (it provides that userland bit of the camera gadget). But gdb does work great over the hardware serial port using an FTDI cable.

It should be quite simple to get you a login prompt or ppp over the one serial-over-USB we have, we would just disable the JeVois CLI when you use that one instead. Would a simple getty work for you?
Ah, the endpoint limit is probably what I hit when I was playing about with the kernel code myself.

Swapping the jevois console for a getty on demand should work pretty well, actually.
0 votes

I'm really hoping you seriously consider the simpleCV extensions to openCV and choose the python that works with both products.  


answered May 24 by badly-bent (140 points)
edited May 24 by badly-bent
yes, thanks for the link! Since that code is a bit old, it will boil down to whether we can still get it to work with the more recent environment we have on JeVois.
Unfortunately SimpleCV has been defunct since about 2014. It's dependent on so many old versions of libraries (the worst being OpenCV, it uses the old API that's been completely removed since) that I can't see a way for it to be included unless someone steps up to update and actively maintain a fork.

The standard OpenCV python bindings are actually very good now, and aren't that much more complicated than SimpleCV was. My recommendation is to bite the bullet and learn to use that directly.