juerg asked for fullscreen gui .. and since I was polishing in the area - we now have fullscreen mrl.

The fullscreen button is a toggle button -

  • hit it once and it goes fullscreen
  • hit it again and it leaves fullscreen
  • again - full screen
  • if you quit in fullscreen (alt-F4) - then it will remember that the next time it starts - it should start in fullscreen
  • you might notice some of the other buttons growing too 
  • desktop is the concept that you can "undock" and move stuff around - and mrl will remember where you moved stuff - so the next time you start (and hit explode)  - the dockable tabs will explode out of the frame and into the place where you last moved them
  • its buggy - but its getting closer 
  • if things get 'too' wacky' you can always delete the gui.json and it will be back to 'normal'

 

You might be thinking to yourself ...  Well, that's cool, but why do you have buttons in a tab to change the gui .. vs.  why didn't you add them to the top frame menu - like the help menu?  (That's what I asked myself)

There is really a reason to always keep stuff in the tabs.  The reason is if two (or more) MRL instances are attached to one another.  You'll have remote gui tabs in your control, and pontentially, you can controll the remote fullscreen, and explode, and all (if coded right) the functionality a gui service has on a remote machine.  (Now just send a video feed of screen captures - and we have remote desktop :D)

juerg

7 years 7 months ago

unbeatable immediate respond to feature request - how can a day start better?
did you also see what went wrong with my i2c connection with the bno055?

Hi Juerg

This is really frustrating. Somebody has made major incorrect changes to the i2c implementation on the Arduino / MRLComm without testing it. 

/Mats

Hopefully it wasn't me, but percentage of change per capita - I would be a likely candidate...

I have very little I2C devices, so on a physical level it would be difficult for me to test, however,
I created the VirtualArduino to help with these sorts of challenges.

It would be great if the continuous integration would test more ..  the VirtualArduino and its derived devices should allow this.

I'll start looking at a service/Bno55.py and see if i can begin building a comprable virtual Bno55 to run against.

Sorry if it was me.

Hi GroG and Juerg

I will fix the broken code in the Arduino service and MRLComm.

Virtual devices are nice, but they are also code, and can behave different than the real device. When I change the Arduino /MRLComm code, will I have to make a similar change to the VirtalArduino ? i

i2c devices are cheap. You only need one type, like for example the ads1115 A/D converter to be able to test both i2c reads and writes. And it cost about 2$.

I think just adding some test methods for Arduino i2cRead and i2cWrite could help detecting when somebody removes neccessary parameters from a method. 

The bus is neccessary to have as a parameter in the i2cRead and i2cWrite methods, because all i2c devices on the same Arduinoi share the same i2cBus ( 1 bus = one SDA and one SCL ). And each i2cBus is a single MRLComm device. I think you may have been confused by that, and that I only implemented using a single i2cBus in the Arduino code.

 /Mats

 

Virtual devices are nice, but they are also code, and can behave different than the real device. When I change the Arduino /MRLComm code, will I have to make a similar change to the VirtalArduino ? i

Yes, maintenance to tests is necessary typically.  Its a balancing act between being too brittle and too much maintenance to tests vs not good enough tests.

i2c devices are cheap. You only need one type, like for example the ads1115 A/D converter to be able to test both i2c reads and writes. And it cost about 2$.

I'm really interested in a Bno055 for telerobotics - I'll order a couple

I think just adding some test methods for Arduino i2cRead and i2cWrite could help detecting when somebody removes neccessary parameters from a method. 

I agree.

The bus is neccessary to have as a parameter in the i2cRead and i2cWrite methods, because all i2c devices on the same Arduinoi share the same i2cBus ( 1 bus = one SDA and one SCL ). And each i2cBus is a single MRLComm device. I think you may have been confused by that, and that I only implemented using a single i2cBus in the Arduino code.

Can you link me to the change so I understand.

Hi

After proofreading the code I found that the prolem was very small. It was because of an incorrect debug statement, and that the i2c code was working well. I was just confused because I didn't recognize the code, since it had gone thru a major refactoring. 

I made a minor change to a failing debug statement and a small change to the i2cWriteRead method in MRLComm.

So please test if the bno055 also works. I tested with the Adafruit16CServodriver service and the Mpu6050 service and they both work as expected.

After reading that the i2c exception is fixed I gave a new try with my self leveling hand.
Unfortunately it looks like "getOrientationEuler()" only returns zero values for yaw, roll, pitch
 
Tried to look through the code but it's so split up that I am not able to see what is finally going on
 
In i01.right.serial - monitor I see this data sent:
170 001 002 
170 006 017 011 040 002 007 000 
170 005 018 011 040 006 026 
170 006 017 011 040 002 007 000 
170 005 018 011 040 001 059 
 
and this received:
170 035
003 055 001 002 197 023 021 000 026 001 002 003 004 005 006 007 008 
009 010 011 012 013 005 000 180 000 053 000 020 000 041 018 000 041 013 
170 002 009 002 
170 002 009 017 
170 009 019 011 006 000 000 000 000 000 000 
170 002 009 018 
170 002 009 017 
170 004 019 011 001 000 
170 002 009 018 
170 035
003 055 001 002 197 023 021 000 026 001 002 003 004 005 006 007 008
009 010 011 012 013 005 000 180 000 053 000 001 000 041 018 000 041 013 
 
Can anybody see why in my python code I get only zeros?
 event = bno.getOrientationEuler()
    print "yaw,roll,pitch"
    print event.yaw, event.roll, event.pitch