Wow ! ... what a huge bunch of fixes and cleanup kwatters and I put into Servo.  Really great having 2+ sets of eyes to get things done right !

This is a quick post to address a few minor remaining items.

We found a deadlock occur when the sweep function i implemented in Java-land was activated by a MrlComm event/call back to change direction.  I changed the sweeping code to use a buffered/thread switching using send("moveTo") instead of a direct moveTo call.  This fixed the problem, but has me worried as I see that basic logic - (getting events then providing control) would be a common use case.

I would propose that calling methods to mrlcomm block on acks, but callbacks are buffered.

I think (but am not sure - this just means a callback from mrlcomm gets acked by the reader, then the reader thread calls a buffered send to publish).

Another fun bug .. is although the sweep is great, and moves with current specified speed, and is very smooth -- I've noticed after a while it range shrinks ! ... I suspect a position problem in mrlcomm

kwatters

4 years 7 months ago

here's a test on harry.. it's letting me drag the servo position outside of the "input" range.

note below.. i have called 

i01.map(10,80,10,80)  

reloaded the webgui

and dragged the slider.. it let me pull it to 109...  the servo did not move there.the output was still properly limited.. but the input should not be allowed to be dragged outside of that range in my opionion.

 

 

Also..  Servo.setMinMax() change needs to be updated .. we set the behavior to set only the minY maxY of the mapper.  The calibrations scripts expected  setMinMax(min,max)  to set min=minX=minY  and max=maxX=MaxY  

I noticed this because harry's movements were all very uncalibrated... and basically all the moves were 1/2 as far as i expected as a result of that change.

Hola Kwatters!!!

I was reading your comments on the shoutbox but I didn't want to interrupt because you and Grog were working very focused.

I have noticed that, I wanted to fix it as I commented here:
http://myrobotlab.org/content/servogui-round-2#comment-11716

With the "Rest" you can also set it out of range. I still don't understand if Rest has to be within the input or output range?

I take this moment without disturbing the shoutbox, to show you this that I started a while ago.

http://myrobotlab.org/sites/default/files/users/user1891images/20200522_202223.jpg

 

driver simulator?

:)

Yes, that is another unfinished project. Everything works except the movement part because I have to change the controller, I had made a DIY one with mosfets, but I am going to change for some Monster drivers.

It is on hold, but can be used stationary to run races.

I use x-sim. I'm just now thinking maybe there is something in there that might be useful in MRL.

https://x-sim.de/software.php?lang=eng

 

again ... you are my hero ;)

The DIY motion shows a high torque .. relatively low rpm motor ?  
Where is the motion in the device ?

Is it similar to this ?

 

 

wonder if that has bimba cylinders.

Do you have 2 motors driving the corners up and down of the front of the seat?

How did you come across this? 

As for the software .. I'd be very curious to see how it looked.  We have motor controls & controllers in mrl, but they need some cleaning and web uis 

Is it similar to this ?

Oh I wish!
Mine is much more modest, with wood, screws and wiper motors.

Do you have 2 motors driving the corners up and down of the front of the seat?
From the back.

Sorry for the dirt, the spider web and the mess. I have to redo all that part of the wiring and make it cleaner.


How did you come across this?

I started in 2005 when I discovered the Colin McRae Rally game. And I couldn't stop. I found x-sim that used a board programming an integrated, it was an H-bridge, but it used a board PARALAX that was impossible to get here. Years later I saw that someone had been able to do it with an Arduino, and there the madness began and I could not stop.
Some games have telemetry and that program can read and convert it to use as a position. For other old games that don't have telemetry, they use directx information. The motors are from wiper motors and if the seat is well balanced they are enough to move it, not as much as in that video. Stronger movements can only be achieved with much larger motors, pneumatic or hydraulic systems, which make everything very expensive.
The potentiometers always broke until I could get from outside the country, some 360º Bourns.

wonder if that has bimba cylinders.
I've never heard of that.

As for the software ...
Yes, I don't know how I thought about it before, it may have something in common or something that can give ideas. Is like the DIY servo. It has a whole logical part about acceleration, PID,  curves and other things that I don't remember, I haven't used it for a long time, the project stopped there because I didn't have time to dedicate to it.

 

Fixed on webgui_work branch

Pos input from user can not go past input limit, same with rest.

Input & Output sliders use the map command, but are defaulted to be "locked" together - which is what most users want. When you unlock input and output can be adjusted independently.

Hopefully, Astro can do his magic making the new lock toggle & sliders look better and more clean. 

I was finally able to get it working.

This is what I was thinking about because I did not understand how the user interprets the Rest if it is part of the input.
In this situation, how does the user know if the status has reached the Rest?
Or does that not matter because we only care about the input and the output is used internally to move the servo?

If so, I have to think again, because I thought Rest was inside the output.
When working inside the input, graphically the position of Rest in this case above the blue bar is confusing. In this case 139.33 is the status Rest.

Perhaps it would be useful here to have a "Go to Rest" button to test the calibration.
Or do we have to graph 2 Rest?
 

Or does that not matter because we only care about the input and the output is used internally to move the servo?

Correct.  Rest is input set by the user (default 90).. and when a servo.rest() command takes place it goes to that (input) location.  Sure - you could add a rest button <button ng-click="msg.rest()"/>

The location for the Rest position doesn't bother me - but your welcome to move it to the input side if it makes sense to you.

graph 2 Rest ?

@Astro,

I really like the latest graphical servoUI !!

Really clear for users, I really love it!

1-I would suggest though to invert the input and the output sliders to match the process order.

2-increase the font and arrows for the rest slider

3-The only thing that can be annoying is not having the possibility to write type the numbers instead of moving sliders. When using finger mouse on a tablet, it can be difficult to get accurate positionning for the sliders or for to set the speed. But this is just a small remark and I really don't want things to be changed if it it is going to take too much time.

3-@grog, InMoov shouldn't have the sliders locked by default, that is wrong. I tried to modify the InMoov2.java concerning the MinMax because it's not correct since setMap was removed, but I would get errors when compiling. So I made some annotations in the java to explain and pushed them. The problem is that you confuse our values for the input into the output.

Thanks Gael, I'm glad you like it.

1- Then I will put the control above with input and Rest and the status below with output.

2- Right! It's too small.

3- Correct! I tried from the cell phone and it is difficult to locate it correctly, the numeric fields can be the solution for those touch devices. But space is an issue for Speed where the slider and a number field no longer fit. We can remove the speed slider and only put the numeric field with a Speed [140] (Set) button.

But now I think that we would have again the problem of Full speed if we put an input field, with the slider is solved in 501.

For input and output limits it can be chaotic visually if we add more fields and buttons that do the same.

I'm going to think a little bit about how to solve this.
 

I changed the top part for input fields, this way in a touch device the keyboard opens.


 

But we need Grog's help here (1) 
because the values only change the green bar (2)
when it should actually change the range (3) and I don't know how to do that.

Same for Rest, just move the div, but don't set the value.

Pushed!
 

Sure, I'd be glad to help..
I have to finish up a large mundane update first - hoping to be finished with "get meta data" update end of day today, then I can get back on webgui_work and make it worky ;)

Wow !
So cool astro.

It might take me a little while to fix this.
 

Maybe if I explain it will help you understand.

There are 2 things you can do with services.  
You can :

  1. Control them
  2. Look at their Status

Sounds simple no ?  

It is until UI components combine the 2 very different things into 1 thing.  Then we have problems.

Here is an example:
Is a slider showing you what the min input "is" or when you change it is it showing you the value you "want it to be" ?   2 concepts 1 slider :(

Same goes for the Input Min component.  Is this "status" the value for which the service.mapper.minX "is" or is it the value you want it to be ?

Not only does this become difficult to implement when the UI components do not make this distinction, but it can actually make crazy feedback loops.  Where you move the slider, it sends a msg to update the service.mapper.minX, and updateService(service) callback comes back which updates the service.mapper.minX which causes a ng-change event which causes another update ..... etc etc ....

If Status is different than Control in the UI these problems do not happen.   Right now the status is seperate from control in the position slider.  Status the "grey position info" is not the same as Control slider handle.

Hi Grog!

It is until UI components combine the 2 very different things into 1 thing.  Then we have problems.

I know, but I just overlapped the sliders and changed their appearance with css. But there are still the 3 sliders that you programmed. I did not modify its operation.

I already found out how I had to do it and now it works and I better than before. :)

I also tried to put what Gael asked me from the notifications below always in the footer, but there, you are going to have to work because you need to include something in js.

Pushed!

Update:
Now I remember that you said something about javaland and what you just described might have something to do with this?
I see it working but am I doing it wrong?

I changed all the variables for example
I use inputSlider.minValue instead of service.mapper.minY

I only changed it in Limits, in Basic and Advanced, there are still the rest,  green and blue rest bars with the variables as before if you want to compare their behavior.

 

Hi astro,

Looks like you got it working the way you want it ... is that correct?

I see it working but am I doing it wrong?

We have a saying .. Worky is King !

Is the Servo UI all done ? It looks great, and it appears to work great too :D

D'oh!

I was excited to answer because when I was reading your answer I thought I had already solved it and I thought I understood how to edit in ServoGui.js. I thought it worked perfectly and I did the push.

Test from the PC perfect!

So I went to see the terminator to really test the calibration with a servo and I did it next to it with the cell phone, and it worked perfect!

BUT, when I went to see on the computer, the values no longer matched.
There I could see what you were telling me that only the status of the servo is the only thing that matches.

If I go to Basic or Advanced tab they are still using variables like
service.mapper.maxY
it looks right

So what I put in the ServoGui.js and in ServoGui.html is wrong.
In other words, it works well, as long as you are doing it from the same device.
But I don't know if that is set by script or in javaland, it could also be a problem.

In my case I use the cell phone to calibrate the limits because the computer is far from the terminator and I can't see his fingers. That is why I discovered it.

I also realized what Gael was saying about the inputLock.
The InputLock should not be active by default because if you do not remember to deactivate it every time you enter, when you touch on one slider, you lose the calibration of the other. From what I understand the status of InputLock is not saved in the configuration, it is always active by default.

For example if you go to Limits and want to change the max ouput from 145 to 140 and you didn't remember to disable the lock:

you lose the input calibration.

If locked is very useful outside of InMoov, perhaps it could be set by default to unlock if the InMoov service is loaded.