Next-steps?
al...@paranoici.org
How are you, are you coming back from holidays?
We are beginning to start an experimental
educational project using Linux, wiimote
python-whiteboard and Ardesia with 40 teachers
I want try to say you the feature priority
- Solve the problem about the fullscreen calibration freeze
that it occurs sometimes
- Some teachers say that they have connection problem with
the last deb, we must investigate on it
- I have seen that the right click that shoot after a "long"
pressure is a standard in the mobile tangible devices
and all the pen and touch devices. I think that it is
a very important feature
I think that solved this issues and after a good testing
can be also do a 1.0, the 2.0 would contain the two wiimote
support and dream 3.0 release the multitouch stuff
(I'm optimistic and I'm joking a little bit)
In the other side there are a lot of teachers that ask
for a windows support. I ask you if there are some coders
or students with C# expertises available to try to work
on this side (So do I'm investigating on this)
I need help in the Ardesia project also
I'm available in the python-whiteboard to make testing,
translation, give feedback and solve bug
Cheers bye, and thanks a lot to all for you work!
---
Pere Negre
<al...@paranoici.org> wrote:
> Hi,
>
> How are you, are you coming back from holidays?
Yeah. Next monday classes begin.
> We are beginning to start an experimental
> educational project using Linux, wiimote
> python-whiteboard and Ardesia with 40 teachers
>
> I want try to say you the feature priority
>
> - Solve the problem about the fullscreen calibration freeze
> that it occurs sometimes
I've been trying to reproduce this bug in my computer, but I haven't
seen this bug yet. The problem may be a race condition. It's difficult
for me to fix this problem if I can't see it.
> - Some teachers say that they have connection problem with
> the last deb, we must investigate on it
There are no changes in the latest deb with respect to the connection
code. It happens sometimes? Maybe it's hardware-related...
> - I have seen that the right click that shoot after a "long"
> pressure is a standard in the mobile tangible devices
> and all the pen and touch devices. I think that it is
> a very important feature
Well, for me it's not a priority. But I can implement the feature and
the user can enable it in the settings dialog. Do you agree?
> I think that solved this issues and after a good testing
> can be also do a 1.0, the 2.0 would contain the two wiimote
> support and dream 3.0 release the multitouch stuff
> (I'm optimistic and I'm joking a little bit)
Hehe... maybe... depends on my workload. We are beginning classes...
so, now I'm very busy with non-programming issues (updating the
subject's paperwork, meetings, etc...)
> In the other side there are a lot of teachers that ask
> for a windows support. I ask you if there are some coders
> or students with C# expertises available to try to work
> on this side (So do I'm investigating on this)
I can't help you with that issue. I'm not really interested in windows
programming (so, a port by me it's unlikely). But there are already
good wiiboard apps in windows...
> I need help in the Ardesia project also
>
> I'm available in the python-whiteboard to make testing,
> translation, give feedback and solve bug
Your interest and ideas have helped a great deal to the project. A big
Thank you too!!!
--
Pere
al...@paranoici.org
Pere Negre <pere....@gmail.com> ha scritto:
> On Thu, Sep 9, 2010 at 10:49 AM, al...@paranoici.org
> <al...@paranoici.org> wrote:
> > Hi,
> >
> > How are you, are you coming back from holidays?
>
> Yeah. Next monday classes begin.
>
> > We are beginning to start an experimental
> > educational project using Linux, wiimote
> > python-whiteboard and Ardesia with 40 teachers
> >
> > I want try to say you the feature priority
> >
> > - Solve the problem about the fullscreen calibration freeze
> > that it occurs sometimes
>
> I've been trying to reproduce this bug in my computer, but I haven't
> seen this bug yet. The problem may be a race condition. It's difficult
> for me to fix this problem if I can't see it.
>
> > - Some teachers say that they have connection problem with
> > the last deb, we must investigate on it
>
> There are no changes in the latest deb with respect to the connection
> code. It happens sometimes? Maybe it's hardware-related...
I haven't idea I'll investigate furthermore...
>
> > - I have seen that the right click that shoot after a "long"
> > pressure is a standard in the mobile tangible devices
> > and all the pen and touch devices. I think that it is
> > a very important feature
>
> Well, for me it's not a priority. But I can implement the feature and
> the user can enable it in the settings dialog. Do you agree?
Yes can also be set as default. I have done to this an hight
priority because the user expect this behaviour
>
> > I think that solved this issues and after a good testing
> > can be also do a 1.0, the 2.0 would contain the two wiimote
> > support and dream 3.0 release the multitouch stuff
> > (I'm optimistic and I'm joking a little bit)
>
> Hehe... maybe... depends on my workload. We are beginning classes...
> so, now I'm very busy with non-programming issues (updating the
> subject's paperwork, meetings, etc...)
No problem ca be possible that there are other willing and good koders
>
> > In the other side there are a lot of teachers that ask
> > for a windows support. I ask you if there are some coders
> > or students with C# expertises available to try to work
> > on this side (So do I'm investigating on this)
>
> I can't help you with that issue. I'm not really interested in windows
> programming (so, a port by me it's unlikely). But there are already
> good wiiboard apps in windows...
So do I'm not interested on windows but the user yep.
The problem for the windows users is for the windows7
at 64 bit there are no free source drivers
>
> > I need help in the Ardesia project also
Thanx
> >
> > I'm available in the python-whiteboard to make testing,
> > translation, give feedback and solve bug
>
> Your interest and ideas have helped a great deal to the project. A big
> Thank you too!!!
>
Cheers bye
--
Pere Negre
Now I can't dedicate time to any programming task. The return to work is tough.
Maybe in a few days I can work on the new features.
--
Pere
al...@paranoici.org
Pere Negre <pere....@gmail.com> ha scritto:
> Sorry for the late reply.
How are you?
We are working a lot and we have written an article
in an italian journal about wiimote-whiteboard using
python-whiteboard and Ardesia
As soon as possible I'll send you the article and some poster...
Using python-whiteboard seems that the great problem is
connect a wiimote when there are a lot of bluetooth devices
It seems that the python-whiteboard try to scan all the devices
and sometimes exit from the connect wizard before that it find the
device,
anyway when there are a lot of people and phones, we sweat to
make the wiimote connection
I suppose that the problem can be soothe
trying to connect directly to the preferred device
without scan, only if it is not found we'll be start
the scanning of all the bluetooth devices
This is' just a hypothesis that might to be checked
I take the opportunity to say you that the 23 Oct we are involved
in wiimote whiteboard live demos and seminars for the Linux Day
in some italian city
@Pere can you try to see the "connection problem" and say me if is
possible make a patch to solve it
Cheers bye
--
Pere Negre
<al...@paranoici.org> wrote:
> I suppose that the problem can be soothe
> trying to connect directly to the preferred device
> without scan, only if it is not found we'll be start
> the scanning of all the bluetooth devices
I've made a little adjustement to the connection code. Now it only
scans if the specified mac is not provided. That should solve the
connection problems when you have the mac address already registrated
in the program.
It's only in the git repository. If you want I can generate a new .deb
with this changes.
The connection problem will persist if "all addresses" are selected in
the configuration dialog.
--
Pere
Pere Negre
dialog that informs you how many devices have been detected and let
you choose the one you want.
The detection method has been improved too. Let me know how it works
for you, Pietro.
--
Pere
al...@paranoici.org
Pere Negre <pere....@gmail.com> ha scritto:
> More changes: Now there is a button that appears in the connection
> dialog that informs you how many devices have been detected and let
> you choose the one you want.
>
I have test these and works fine, I have only a doubt
As or not sense scan when you have configured a fixed device,
the scan of devices can take a lot of time... if there are many devices
It is sure that visualize the bluetooth devices can be useful to
ask to the students to switch off the phone also
An other point; I have seen that in some resolution the point are
outside the screen and it is so strange for me
Might be possible calculate the corner screen where visualize the
calibration point starting from the screen resolution
and the calculate the point
e.g. in a like C pseudo code
width = screen_get_width();
height = screen_get_height();
distance_from_corner=40;
radius=20;
first_point = alloc_point();
first_point->x = 0 + distance_from_corner;
first_point->y = 0 + distance_from_corner;
second_point = alloc_point();
second_point->x = width - distance_from_corner;
second_point->y = 0 + distance_from_corner;
third_point = alloc_point();
third_point->x = width - distance_from_corner;
third_point->y = height - distance_from_corner;
fourth_point = alloc_point();
fourth_point->x = 0 + distance_from_corner;
fourth_point->y = height - distance_from_corner;
draw_circle(first_point, radius);
draw_circle(second_point, radius);
draw_circle(third_point, radius);
draw_circle(fourth_point, radius);
Or something like this; in this way you might have
four point closed to the corners
A similar algorithm can be generalized to make a calibration grid
with more points and try to see if the setup will work better
In this way could be erased the code for move the point... making the
code cleaner
Cheers bye and thank you
Pere Negre
Il giorno Tue, 12 Oct 2010 19:12:34 +0200
> More changes: Now there is a button that appears in the connectionI have test these and works fine, I have only a doubt
> dialog that informs you how many devices have been detected and let
> you choose the one you want.
>
As or not sense scan when you have configured a fixed device,
the scan of devices can take a lot of time... if there are many devices
It is sure that visualize the bluetooth devices can be useful to
ask to the students to switch off the phone also
An other point; I have seen that in some resolution the point are
outside the screen and it is so strange for me
Might be possible calculate the corner screen where visualize the
calibration point starting from the screen resolution
and the calculate the point
--
Pere
al...@paranoici.org
wrote:
> On Tue, Oct 19, 2010 at 7:37 PM, al...@paranoici.org [1] wrote:
> Il giorno Tue, 12 Oct 2010 19:12:34 +0200
>
>
>> More changes: Now there is a button that appears in the connection
> > dialog that informs you how many devices have been detected and
> let
> > you choose the one you want.
> >
>
> I have test these and works fine, I have only a doubt
> As or not sense scan when you have configured a fixed device,
> the scan of devices can take a lot of time... if there are many
> devices
>
> It is sure that visualize the bluetooth devices can be useful to
> ask to the students to switch off the phone also
>
> I'll look into that. The program should not scan for new devices if
> the user has chosen a fixed device.
>
> An other point; I have seen that in some resolution the point are
> outside the screen and it is so strange for me
>
> Might be possible calculate the corner screen where visualize the
> calibration point starting from the screen resolution
> and the calculate the point
>
> This is strange, because I'm doing it in the way you are saying.
> Check http://github.com/pnegre/python-whiteboard/blob/master/stuff/calibration.py
> screen resolution.
>
> I've tested the program in various screen configurations and it
> correctly draws the calibration points.
>
> Can you tell me the screen configuration's details of your case?
Good, I have forwarded a problem of a newbie teacher,
it is possible that he has done something wrongly
with the projection resolution also; I'll investigate furthermore
I'm testing a lot python-whiteboard and sometimes occurs two bugs:
1) freeze of the calibration phase (not hight, I press ESC and redo it)
2) Sometime the mouse remain pressed after the IR pen switch-off also,
the problem persists after the quit of the program also (critical)
3) The move only feature; I have not tested it but some people say
this,
as soon as possible I'll do some test, to test it can be sufficient
put in "move only", move the cursor with the light pen and click
with the mouse button or pad
I have seen that the teachers aprechiate a lot the right click feature
and
are happy that the mouse has not the right click that shot after a
timeslice;
I think that is not the case to change the click system anymore,
when these bugs will be solved and a good test
I can say that I expect that the pointer is moved in the place taken
from cwiid
and it is moved in the right place,
if the drive is not in the "move only" mode the first that the driver
see the light emulates
the button pressure if a timeslice without see the light occurs then
will be emulated the button lease
Or somethink like that
I have seen that now you use the xtest lib, I can ask you if you can
try to use
directly the xlib instead; this will be very good to make some test
about multipointer
with XWarpPointer for move the cursor and with the XSendEvent
These functions must be followed by the XFlush to send syncronously the
event
Here there are a thread about how use these in python:
https://bbs.archlinux.org/viewtopic.php?pid=725523
In this way will be easy use the XIWarpPointer and the other xinput2
routines;
at the moment you could use the core pointer and in the future will
create two
device to allow to use two mouse; I'm strongly motivated to build a
multipoint
whiteboard and I think that in Jan I'll can start to work on this and
I'm considering to use python-whiteboard or part of it
I think that the program could be ready to a 1.0 with the features
already implemented frozen
after some intermediate better versions.
Thanks
al...@paranoici.org
I send the article about the Wiimote whiteboard
published in an Italian Linux magazine
You can get this on http://dl.dropbox.com/u/2265205/Wiild.pdf.zip
In the Italian Linux Day the Wiimote whiteboard was a
big theme inside the Open Source and school theme
and it was very appreciated by the people
Thanks a lot to all for the great work!
Pietro
Pere Negre
Hi,
I send the article about the Wiimote whiteboard
published in an Italian Linux magazine
You can get this on http://dl.dropbox.com/u/2265205/Wiild.pdf.zip
--
Pere
al...@paranoici.org
wrote:
> On Tue, Oct 26, 2010 at 3:27 PM, al...@paranoici.org [1] wrote:
> Hi,
> I send the article about the Wiimote whiteboard
> published in an Italian Linux magazine
>
> You can get this on http://dl.dropbox.com/u/2265205/Wiild.pdf.zip
>
> Oh, great!!!
>
> I tried to read it (spanish and italian are similar). I would like to
> thank you for the continous support to this project. I appreciate your
> effort to give me directions and feedback. I'm sure that this article
> on the italian linux magazine will serve to publicize
> python-whiteboard and ardesia further.
That's it!
In Italia the greatest theme on the Linux Day was the wiimote
whiteboard,
let's read the article on the Repubblica (one of the most read italian
daily newspaper)
http://www.repubblica.it/tecnologia/2010/10/23/news/linux_day_2010-8360079/
This is thanks to our work and the italian community enthusiasm
You could try to publish an article similar to Linux Pro one, also...
Thanks for your effort, bye
Pere Negre
That's it!In Italia the greatest theme on the Linux Day was the wiimote
whiteboard,
let's read the article on the Repubblica (one of the most read italian
daily newspaper)
http://www.repubblica.it/tecnologia/2010/10/23/news/linux_day_2010-8360079/
This is thanks to our work and the italian community enthusiasm
You could try to publish an article similar to Linux Pro one, also...
Thanks for your effort, bye
--
Pere
al...@paranoici.org
Pere Negre <pere....@gmail.com> ha scritto:
> >
Hi Pere I have done a conference and a teacher say that
he prefers an other wiimote driver that in called gtkwhiteboard
it has not a lot of option but it works pretty well and it is very
old and unmantained
We have seen that it is more precise that python-whiteboard
to the location where put the mouse
Can be a more precise matrix algorithm?
The very interesting thing of that project is that it is written
in python and it is crossplattform; it use the wiimotelib
I think that the more reactiveness of the gtkwhiteboard can derive
from the library used
We have seen also a strange behaviour in python-whiteboard
making a fast movement the pointer doesn't stop when we switch off
the IR light pen but it continue to move in the given direction
for a bit, such as have an inertial force
Can be that this is done from a prediction that you use to smooth the
line?
Anyway I think that you could read the gtkwhiteboard code to see if
there are interesting things useful to improve the python-whiteboard
tool
The more interesting code is perspective.py with the matrix issue
the mousecontrolpy (that it has the code to move and click for win and
linux) and the linuxWiimoteLib.py with the code to access to the
wiimote data
I think that if it is no difficult pass to the linuxWiimoteLib and
the mouse routines can be a good effort to have the python-whiteboard
runnable on windows
Links:
http://www.stepd.ca/gtkwhiteboard/
Cheers bye
--
Pere Negre
Hi Pere I have done a conference and a teacher say that
he prefers an other wiimote driver that in called gtkwhiteboard
it has not a lot of option but it works pretty well and it is very
old and unmantained
We have seen that it is more precise that python-whiteboard
to the location where put the mouse
Can be a more precise matrix algorithm?
The very interesting thing of that project is that it is written
in python and it is crossplattform; it use the wiimotelib
I think that the more reactiveness of the gtkwhiteboard can derive
from the library used
We have seen also a strange behaviour in python-whiteboard
making a fast movement the pointer doesn't stop when we switch off
the IR light pen but it continue to move in the given direction
for a bit, such as have an inertial force
Can be that this is done from a prediction that you use to smooth the
line?
I think that if it is no difficult pass to the linuxWiimoteLib and
the mouse routines can be a good effort to have the python-whiteboard
runnable on windows
--
Pere
al...@paranoici.org
wrote:
> Hi Pere I have done a conference and a teacher say that
> he prefers an other wiimote driver that in called gtkwhiteboard
> it has not a lot of option but it works pretty well and it is very
> old and unmantained
>
> We have seen that it is more precise that python-whiteboard
> to the location where put the mouse
> Can be a more precise matrix algorithm?
>
> I don't think so. Maybe the fault it's in the calibration process
> (the gathering of the calibration points in fullscreen mode). But the
> algorithm I think is right and precise.
>
> The very interesting thing of that project is that it is written
> in python and it is crossplattform; it use the wiimotelib
>
> I think that the more reactiveness of the gtkwhiteboard can derive
> from the library used
>
> It's actually very probable. I used cwiid. gtkwhiteboard uses the
> bluetooth library alone for interfacing with the wii device. It's
> possible to reuse the same classes and maybe make python-whiteboard
> faster. I'll look into it.
>
Good, may be that works well
I think that you can try to use the gtk-whitoboard
to see the behaviour
> We have seen also a strange behaviour in python-whiteboard
> making a fast movement the pointer doesn't stop when we switch off
> the IR light pen but it continue to move in the given direction
> for a bit, such as have an inertial force
>
> Can be that this is done from a prediction that you use to smooth
> the
> line?
>
> Yes, the smoothing algorithm can produce these effects. gtkwhiteboard
> has cursor smoothing?
No gtkwhiteboard hasn't, the point is that the smoothing can be useful
in same cases but not apreciated in other (anyway it is
configurable...)
I thing that in any case each new point detected might be moved
with the inertia to be smoothed but when the Ir light is switch off
this might stop the cursor immediatly;
sorry if a make some supposition but I am not able to read the code...
The idea is that the smooth correct the detected point and
don't add new one
(it is also possible that is not the case, I haven't idea about that)
> I think that if it is no difficult pass to the linuxWiimoteLib and
> the mouse routines can be a good effort to have the
> python-whiteboard
> runnable on windows
>
> Maybe. But I really have no interest in making the program run in
> windows. If someone want to do it, it's fine by me.
So do I am not interested but many people are
In any case I'm looking for a student that can help me
in the wiimote whiteboard stuff, Ardesia and Co; we'll see
The window porting can be a litte task for a student
As soon as possible I'll release the new Ardesia
and I'll beginning the port on Mac
(I'm payed for this task and it is the first time that
I have some money for the Ardesia work and I can't refuse)
I don't know if you are interested or not but i think that (but I'm not
sure)
the WiimoteLib run on Mac also; could be great have a cross plattform
python-whiteboard, now all use closed source programs or the uwe one's
Thanks a lot for your work, bye
al...@paranoici.org
I have seen that in the python-whiteboard
readme there are some missing requirements
python-cwiid, python-bluez python-xlib
I have an other issue, it is possible to avoid
the starting of a second instance of python-whiteboard.
A lot of times when we try and retry occurs to open a second
instance and then we mus kill all
Thans bye
On Fri, 29 Oct 2010 17:27:45 +0200
al...@paranoici.org
I'm Pietro Pilolli and I'm following the project by lot
I would suggest some point to improve the tools that I consider the
best
wiimote whiteboard driver available at the moment:
1) Avoid the starting of a python-whiteboard second instance.
I have seen that a lot of teacher restart the tool when the
python-whiteboad
is hidden. Might be a good thing reshow the old window istead
of start a second instance of the program. This behaviour make user
and computer
confusion.
2) Faster calibration. I have seen that the calibration is "slow";
it take a lot of time and points before finish to colur all the
calibration points. I think that take lesser points or lesser time
can give a better user experience. I'm referring to the so called
fullscreen calibration. Anyway, I think that a time approach can
give better
result. For each point the tool could listen form e.g. 10 or 20
millisecond
the IR point colouring the circe and than go to the next calibration
point.
A different approach could be let the same algorithm and try to
decrease the campionship
number to validate the calibration point.
About this issue I ask you if do you thing that give more that four
calibration point
could give a more precise calibration or not...
3) When I press ESC in calibration window and I push ESC I have a
window that notify
an error in the calibration. I think that is not correct because it
is an explicit use'choice.
In this case I think that the tool might start with the mouse
emulation if a previous calibration matrix
exists or rego in initial state with the connetion estabilished.
4) After the calibration and the mouse activation the python-window
seup window could be hidden
5) Performance issue. I have noticed that the tool has a lot of lags
with pentium 3 and netbook.
In a lot of schools the teachers use this kind of computer. In this
case they use other
whiteboard tool as gtk-whiteboard because they use lesser resource
(in term or cpu or memory).
In any case also gtk-whiteboard is written in python and then I
don't know why python-whiteboard
has more resource usage.
I think that this could be different approaches in order to make the
tool more reactive; there are only some
suggestions to be confirmed and validated:
- Looking for memory leak and fix them
- Free the memory of the qt window when is possible. A generic issue
can be split the program in
twice a configuration setup (the current wizard) in order to write
a configuration file and
a little service that read the conf and start according to the
conf file the mouse emulation
for the wiimote whiteboard.
- Investigate if the library used by gtk-whiteboard are more
performant
- Change the mouse pointer algorithm in order to lighter. Ihink that
we could have a timer
and then neglect the IR wiimote point detected if is not spent a
given timeslice (e.g. 10 millisecond or 20)
And then I have a borning idea to share with you starting from the
problem that the teachers have some problem
when have a low battery IR pen.
Is possible notify in empiric way the low IR pen? I know that the
wiimote give for each point a number that is the
light intensity. Could be possible implement and could be have sense
give a message "please reply the wiimote pen battery"
if this number is low.
Could be auto set the infrared sensibility accoarding to the
environmental and IR light?
An other problem for the teacher occurs when the sunlight hit the
projection surface could be possible detect the situation
reading during the calibration. I expect that if the sun hit the
surface the wiimote will detect some area enlight by IR for all
the calibration. Could be possible suggest to close curtain or shutters
or connue to work ignoring the environment light?
Best regards
matt ledding
Pere Negre
1) Avoid the starting of a python-whiteboard second instance.
I have seen that a lot of teacher restart the tool when the python-whiteboad
is hidden. Might be a good thing reshow the old window istead
of start a second instance of the program. This behaviour make user and computer
confusion.
2) Faster calibration. I have seen that the calibration is "slow";
it take a lot of time and points before finish to colur all the
calibration points. I think that take lesser points or lesser time
can give a better user experience. I'm referring to the so called
fullscreen calibration. Anyway, I think that a time approach can give better
result. For each point the tool could listen form e.g. 10 or 20 millisecond
the IR point colouring the circe and than go to the next calibration point.
A different approach could be let the same algorithm and try to decrease the campionship
number to validate the calibration point.
About this issue I ask you if do you thing that give more that four calibration point
could give a more precise calibration or not...
3) When I press ESC in calibration window and I push ESC I have a window that notify
an error in the calibration. I think that is not correct because it is an explicit use'choice.
In this case I think that the tool might start with the mouse emulation if a previous calibration matrix
exists or rego in initial state with the connetion estabilished.
4) After the calibration and the mouse activation the python-window seup window could be hidden
5) Performance issue. I have noticed that the tool has a lot of lags with pentium 3 and netbook.
In a lot of schools the teachers use this kind of computer. In this case they use other
whiteboard tool as gtk-whiteboard because they use lesser resource (in term or cpu or memory).
In any case also gtk-whiteboard is written in python and then I don't know why python-whiteboard
has more resource usage.
I think that this could be different approaches in order to make the tool more reactive; there are only some
suggestions to be confirmed and validated:
- Looking for memory leak and fix them
- Free the memory of the qt window when is possible. A generic issue can be split the program in
twice a configuration setup (the current wizard) in order to write a configuration file and
a little service that read the conf and start according to the conf file the mouse emulation
for the wiimote whiteboard.
- Investigate if the library used by gtk-whiteboard are more performant
- Change the mouse pointer algorithm in order to lighter. Ihink that we could have a timer
and then neglect the IR wiimote point detected if is not spent a given timeslice (e.g. 10 millisecond or 20)
And then I have a borning idea to share with you starting from the problem that the teachers have some problem
when have a low battery IR pen.
Is possible notify in empiric way the low IR pen? I know that the wiimote give for each point a number that is the
light intensity. Could be possible implement and could be have sense give a message "please reply the wiimote pen battery"
if this number is low.
Could be auto set the infrared sensibility accoarding to the environmental and IR light?
An other problem for the teacher occurs when the sunlight hit the projection surface could be possible detect the situation
reading during the calibration. I expect that if the sun hit the surface the wiimote will detect some area enlight by IR for all
the calibration. Could be possible suggest to close curtain or shutters or connue to work ignoring the environment light?
Pere
Georges Khaznadar
> ... I've coded just now a rudimentary mechanism for ensuring that
> only one instance of the app is running (using lockfiles). It's in the git
I just uploaded a package python-whiteboard_1.0+git20111009-1 to Debian.
It contains a tiny fix for the French l10n too.
Best regards, Georges.
Pere Negre
Pere
al...@paranoici.org
I suggest to release the python-whiteboard 1.0, it works very well
Pietro
al...@paranoici.org
It is a lot of time that we are not see
I want ask you some little emprovement
First of all is it possible to have the smoothing level starting from 0
(then disabled)
An other point lot of user says that in some situation
python-whiteboard
doesn't work but other wiimote whiteboard program yes.
I think that this happen with not well done setup but
they prefer other program and they are happy with them.
I'm investigation about the why and I have some little question
and suggestion to solve these problems
I have read the code about the sensitivity and I think that this could
be the critical point.
First of all I have seen printing the values that a lot messages with
intensity
7 and more are blocked because are higher than the 6 sensitivity level.
Seems that the higher level are the brightest ones.
Other point, I have some doubt about this implementation what mean drop
the point higher then
a setting.
Usually the tracking program make cut the weak light considering
disturbs and then I think that
at the major level it might me take all the data at 0 neglect all and
if it is set to n this make
neglect all the points lighter then a value.
I propose to change the file wiimote.py at line 69 from:
if data['size']
> self.maxIrSensitivity:
continue
if self.funcIR
is not None:
self.funcIR(self.getPos(data['pos']))
return
to:
# This is the
maxlight value seen with cwiid
# the
correctness of this value must be seen
# by doc or
measured; the maximum value of the
# slide might
be this value minus one
# the minimum
value of the slide might be 1
max_lightness=9
if data['size']
< max_lightness - self.maxIrSensitivity:
continue
if self.funcIR
is not None:
self.funcIR(self.getPos(data['pos']))
return
An other point that I have not checked is if the slide value are taken
at runtime. In other word if moving the slide has
immediately change the behaviour
I think that you have done this implementation because the sun light
might be more brighter than
the pen but in this case we cannot done nothing then see the light
before the calibration and ignore
the points in this enlighted areas. This is the so called background
removal. Neglect all the candidates
point to track that are the false friend because they are background
disturb.
I have also one question for you. Do are you watching all the points or
only one of the four seen
by the wiimote?
Pietro Pilolli
al...@paranoici.org
I have change the code in order to use a scale from 1 to 10
for sensivity and smoothing and I have set 10 as default value.
I attach the modified files
I have seen that these configuration settings have immediate settings
and
are valid in the calibration windows also.
Then the my unique open question is
Does python-whiteboard track all the four IR points supported by the
wiimote or only one?
Pietro Pilolli
al...@paranoici.org
the code of wiimote.py
in order to track all the point these give the advantage to follow ir
pen light also if other ir blobs
are dected. Clearly in this way we control a single pointer with
multiple Ir dot and then is possible that
the pointer was stollen beetween different ir light.
A good emprovement could be have a different pointer for each infrared
light. In this way will have a multi pointer
support.
We can think about some algorithm to detect the valid ir source
neglecting the fixed light and the weak ones. Anyway this change does
not have impact in a good setup with no sunlight
on the projected area but it is very useful if you have a sunlight ray
that hit a point in surface; with this change you will
be able to move the whiteboard also.
if m[0] == cwiid.MESG_IR:
max_lightness = 10
for data in m[1]: #
Loop through IR LED sources
# This is the
max_lightness value seen with cwiid;
correctness of this value must be seen
# by doc or
measured; the maximum value of the
# slide might
be this value minus one
# the minimum
if data:
Pere Negre
I've also generated a new .deb package.
--
Pere
Georges Khaznadar
Pere Negre a écrit :
>
> I'm sorry for not responding to this message earlier.
>
> I have incorporated your changes to the git repository. Also, I fixed the
> "systray issue" in Unity (I've disabled it).
I have fetched newest changes from the git, and uploaded a new Debian
packages as version 1.0+git20120728
Best regards, Georges.
Pere Negre
Pere