Recommended Posts

On 7/29/2022 at 4:09 AM, Pybricks said:

 

@Lok24 and @vascolp: We have made some progress in regards to saving data on the hub. How much space would you need to make this a useful feature? 10 bytes? 100? 256? more?

Hi there, I'm wondering if this feature is available in beta, or somewhere else to test?  I'd like to use the color sensor for a GBC ball counter, that can be saved and reloaded each time the hub is started.

Share this post


Link to post
Share on other sites
On 10/4/2022 at 11:51 AM, Ryk Field said:

Hi there, I'm wondering if this feature is available in beta, or somewhere else to test?  I'd like to use the color sensor for a GBC ball counter, that can be saved and reloaded each time the hub is started.

Not yet, but we're laying the groundwork for it as we speak. That includes saving the program on the hub without having to reinstall. :wink:

If you want this feature, it would be great if you want to open an issue here: https://github.com/pybricks/support/issues Thanks!

Share this post


Link to post
Share on other sites

I have two questions:

 

is it possible to control several hubs at the same time? If not yet, is it expected to come at some point?

 

Is the communication between hubs possible? Although it's an alternative to the first question, it works be a great implementation, be I think. 

 

Many thanks!!!

 

 

Share this post


Link to post
Share on other sites
17 minutes ago, HectorMB said:

is it possible to control several hubs at the same time?

 

Who should control them? Pybricks runs standalone on each hub.

17 minutes ago, HectorMB said:

Is the communication between hubs possible?

not yet, you can only connect a remote to a hub. (or multiple remotes? Don't know)

Edited by Lok24

Share this post


Link to post
Share on other sites
11 minutes ago, Lok24 said:

Who should control them? Pybricks runs standalone on each hub.

 

Thanks! Ok, I'm more precise: can a single remote control more than one hub running under Pybricks?

But, from your second answer, the first question is already answered :)

 

then: is it expected to happen at some point?

Share this post


Link to post
Share on other sites
2 minutes ago, HectorMB said:

Ok, I'm more precise: can a single remote control more than one hub running under Pybricks?

I think: no

Share this post


Link to post
Share on other sites

Question for those who have asked about data storage.

What do you think of the following approach?

# There will be 128 bytes you can read and write.
# The data will be saved when you turn the hub off.

# To write some data:
hub.system.storage(offset=5, write=b"Hello, world!")

# To read some data:
data = hub.system.storage(offset=12, read=6)
print(data) # This will print b"world!"

Is this flexible enough? Is there any functionality that seems missing?

Who is excited for this feature? Oh... and what if I told you programs will be saved on the hub without re-installing? :laugh:

Edited by Pybricks
Fixed example code.

Share this post


Link to post
Share on other sites

My needs are simple, a counter that survives a battery change.  This looks awesome.  Thank you!  (Yes, I'm excited!)

I'm curious if you've had any help from Lego regarding the internals of the hubs(plural) functioning, of if you've all had to figure it out yourselves?

Share this post


Link to post
Share on other sites
20 minutes ago, Pybricks said:

What do you think of the following approach?

That looks like a (non-volatile) RAM pool in whose addresses we read and write data. Considering the hubs were never made for such functionality (as far as I guess), that's really cool! :thumbup:

May I suggest an addition? A method that takes generic data and returns the number of bytes it'll take in storage. That way, we'll be able to manage available space and calculate where to store multiple pieces of data. For example, get how many bytes a string will take to know the offset to store an adjacent second string.

20 minutes ago, Pybricks said:

Oh... and what if I told you programs will be saved on the hub without re-installing?

:excited:

Share this post


Link to post
Share on other sites
Quote

May I suggest an addition? A method that takes generic data and returns the number of bytes it'll take in storage. That way, we'll be able to manage available space and calculate where to store multiple pieces of data. For example, get how many bytes a string will take to know the offset to store an adjacent second string.

Good idea. Could what you have in mind perhaps be done with existing MicroPython functions? For example, use

data = b"Hello"
len(data) # This equals 5

 

Quote

I'm curious if you've had any help from Lego regarding the internals of the hubs(plural) functioning, of if you've all had to figure it out yourselves?

We've figured it out -- we've been doing this for a while :classic:. This has been made possible due to a few recent development breakthroughs. A big one came from MicroPython itself. Using their improved file format of compiled programs, we can keep the program in memory after it ends. Then we can properly save it when we power the hub off. This is much easier than saving data while the hub is running, which is what prevented us from doing it until now.

Quote

This looks awesome.  Thank you!  (Yes, I'm excited!)

:laugh:

Share this post


Link to post
Share on other sites
1 minute ago, Pybricks said:

A big one came from MicroPython itself. Using their improved file format of compiled programs, we can keep the program in memory after it ends.

What are the circumstances for data that has been "written" with hub.system.storage(...) when the batteries fail?  Are you able to pre-emptively write to the hub when/if you detect the batteries about to fail (ie, the flashing lights when the batteries are low)?

 

Share this post


Link to post
Share on other sites

Once saved and powered off, your program and data will remain saved even after removing the battery.

Yes, the hub will automatically shutdown on low battery, and the light will start flashing orange before that happens. See: https://pybricks.com/install/using-powered-up-hubs/

User data will automatically be erased when you update the firmware or if you install the original firmware again.

Share this post


Link to post
Share on other sites

Sorry, do we have to notice the low power condition ourselves and terminate the program to force the data to be written, or do you detect that and do it automatically?  Thanks.

Share this post


Link to post
Share on other sites

Both. The blinking light shows when the battery is low, but it is just an indication at that point. The hub will safely turn off later and save data, when the battery is very low.

I imagine you are asking about running a GBC for a long time, not losing count when the batteries run dry? :wink:

But please do help us test when we release it. If something isn't working, we can fix it :)

And, you can do even better if you want to handle it in your own script. You can check the battery level in your code, and turn off/save when the battery goes below your preferred level.

Share this post


Link to post
Share on other sites
Just now, Pybricks said:

But please do help us test when we release it. If something isn't working, we can fix it :)

Yes, i'm up for helping out, absolutely.  Cheers.

Share this post


Link to post
Share on other sites
from pybricks.hubs import CityHub
from pybricks.pupdevices import ColorDistanceSensor, ColorLightMatrix
from pybricks.parameters import Port, Color
from pybricks.tools import wait

# Initialize devices.
hub = CityHub()
sensor = ColorDistanceSensor(Port.A)
lights = ColorLightMatrix(Port.B)

# We want to detect only these colors.
scanned_colors = [Color.NONE, Color.BLUE, Color.RED]
sensor.detectable_colors(scanned_colors)

# Waits for a color.
def wait_for_colors():
    wait(500)
    while sensor.color() != Color.NONE:
        wait(10)
    while sensor.color() == Color.NONE:
        wait(10)
    return sensor.color()

# Load previous data. Bytes 0 to 9 represent colors.
saved_colors = bytearray(hub.system.storage(0, 9))

while True:
    # Dipslay the colors.
    lights.on([scanned_colors[c] for c in saved_colors])

    try:
        # Get index of next empty pixel.
        index = bytes(saved_colors).index(bytes([0]))
    except ValueError:
        # Display full, so start over.
        saved_colors = bytearray(9)
        index = 0

    # Wait for the next color and store it.
    saved_colors[index] = scanned_colors.index(wait_for_colors())   
    hub.system.storage(0, write=bytes(saved_colors))
    
    

 

Share this post


Link to post
Share on other sites

Very nice! I am running the beta version: ' technichub', ' '3.2.0b3', 'v3.2.0b3 on 2022-07-20')
Will there be a new beta version soon where we can use this?

Frans

Share this post


Link to post
Share on other sites

 

8 hours ago, Pybricks said:

What do you think of the following approach?

Is this flexible enough? Is there any functionality that seems missing?

Seems very cool, really what I needed.

8 hours ago, Pybricks said:

Who is excited for this feature? Oh... and what if I told you programs will be saved on the hub without re-installing? :laugh:

Seems very cool too!!! Waiting to undertand this better... does it means that I have to call some function to save the current program or it will be saved "automagicaly"?

So, I am in the IDE front end, write and test some program, [do something to save it] and turn everything off. In the other day I connect to the hub, and the IDE will show me the program stored in the hub instantly?

This seems particularly useful in the development cycle of bigger apps!

Oh more questions... I struggled a lot with the lack of space of the CityHub. How does these features will affect the available space? I supose 128 bytes is 128 bytes less :classic: but a program is a bit bigger...

RemoteBlaBla for TechnicHub is a 47kb source file and for CityHub it is 27kb...  

Do you save source code or compiled code only?

Edited by vascolp

Share this post


Link to post
Share on other sites
7 hours ago, fotoopa said:

Very nice! I am running the beta version: ' technichub', ' '3.2.0b3', 'v3.2.0b3 on 2022-07-20')
Will there be a new beta version soon where we can use this?

Frans

We just released a new beta version a few hours ago. Just go to https://beta.pybricks.com/ . If you were already using it before, the site will update itself a few minutes after you open it.

The version in the about menu should then be: v3.2.0b4 (Pybricks Beta v2.0.0-beta.6).

Then you can install the latest firmware on the hub as usual.

Have fun!

@vascolp: No special actions are needed to save the programs.

Think of it this way - Pybricks basically turns the City/Boost/Technic hub into a mini MINDSTORMS hub :)

Share this post


Link to post
Share on other sites
10 hours ago, Pybricks said:

We just released a new beta version a few hours ago. Just go to https://beta.pybricks.com/ .

Fine. I loaded the new beta version and reading and writing memory data works great. Thank you very much!

I am still missing read and write serial data to and from a hub. With this I would like to link Fischertechnic and Lego to exchange commands between them. Is there any chance this would be available in a new beta version. Now I can do it via remote control on the Technichub. With FT I could do this with servos on the 7 buttons available on a remote. This would involve commands from FT to Lego. With Lego you have very few options for handling digital inputs. With FT this is standard on their TXT controller.

Frans.

Share this post


Link to post
Share on other sites
On 10/21/2022 at 11:30 AM, Pybricks said:

...

We've figured it out -- we've been doing this for a while.
....
Using their improved file format of compiled programs,

...

 

Hello,

I tried to find out how mpy compiling is working but failed.

What for  example would mean :
image.png.675aaf80e364c2a42454e751a3ebf380.png

What I (think to) get till now :
image.png.ac7378b221d04e0198c522918d99d0b4.png

@Pybricks : what is wrong im my understanding ?


Jo

Share this post


Link to post
Share on other sites

Hi @BrickTronic - compiling programs is not Pybricks-specific. It’s the same as all MicroPython boards. Pybricks “just” adds all the code to make MicroPython run on LEGO hubs.

Most of our users don’t have to know all the details, but if you’re curious, you can learn more about the MPY format in the MicroPython documentation and their source code: https://docs.micropython.org/en/latest/reference/mpyfiles.html#binary-encoding-of-mpy-files

Share this post


Link to post
Share on other sites

Hi!

I just tested the new firmware version ('technichub', '3.2.0b4', 'v3.2.0b4 on 2022-10-21').

Tried the storage stuff with a TechnicHub, it seems to work fine!
But got some "GATT unknown error" when doing nasty things like removing bateries while on. After removing the bateries, puting them back, reconnecting to pybricks and running the program, it gave me this error. 

Tried it also with RemoteBlaBla. It does not work immediately because the line:

    from math import trunc

is not needed anymore.
But after commenting it, it seems to work very well! No need to flash it just use it!

I also want to try RemoteBlaBla in a CityHub because it is very memory demanding... but... no charged AAA bateries... maybe tomorrow.


BTW, I was initialy mislead by your post with data/size storage() arguments while they really are read/write... maybe you can edit it...
 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.