[sMOC] Remote Bla Bla

[2GodBDGlory]

I just tested it with these more common tires, and they work tolerably well, mounted on 1L liftarms. They only measure at 14.5mm mounted compared to 15.0 for the space tires, though, and the difference is noticeable. The newer tires only work correctly if one puts slight downward pressure on the control stick, while the space ones work more reliably.

Would it be worthwhile for me to take some more detailed pictures of the controller to help others build it?

[vascolp]

Here is how I have done it, based on your pictures (it´s fantastic what 10 minutes in stud.io can do!)

I didn´t really tested yet, because I don´t have the tires with me...

Regarding integration in RemoteBlaBla, I think only two steps will be possible, or else it would complicate to much the code. 

Building a lever that can handle 3 or more steps (specially more than 3) that will be quite a chalange!

[2GodBDGlory]

3 hours ago, vascolp said:

Here is how I have done it, based on your pictures (it´s fantastic what 10 minutes in stud.io can do!)

I didn´t really tested yet, because I don´t have the tires with me...

 

Regarding integration in RemoteBlaBla, I think only two steps will be possible, or else it would complicate to much the code. 

Building a lever that can handle 3 or more steps (specially more than 3) that will be quite a chalange!

Yeah, that looks like a good equivalent!

Sounds good; even just two steps would be a big improvement.

[gyenesvi]

I have been reading yet another discussion about supporting gamepad controllers in the 2023 sets thread, when I understood something important about this whole system; namely that it is possible to connect the hub and the (lego) remote without an intermediary phone, at least using Pybricks. I am guessing the same is true for the original FW as well, otherwise the existence of the remote would not make much sense. I have been wondering whether making a similar bluetooth connection would be possible to implement for a gamepad controller as well, at least with Pybricks, or if there's something special about the lego remote (such as a special id) that makes it possible? Maybe this should be a question addressed to @Pybricks.

Also, I have now looked more thoroughly into how this whole system is implemented. I understand that the hub cannot store data, hence the profile is encoded in the name of the controller (nice trick). I was wondering if it would actually be possible to encode the profile on the hub. Theoretically, the FW and the python program you bake into it could store the profile. If it was just a single-purpose (non-configurable) program, then the program itself would be the profile data. To keep the configurability, I was wondering if it would be possible to kind of put the encoded profile string into the program, and then bake it onto the hub. It would have the disadvantage that it would require re-baking the FW when the profile is changed, but as I understand that's a quick and easy process. The overall program would remain the same, only a string in its beginning would need to be changed every time. Furthermore, then it would have the advantage that the string could also be generated offline, with a WYSIWYG interface, for example in the browser. Adding to this the maybe possible ability to connect to a gamepad, we could finally have complexly configurable, proportional control, that only needs a computer for the config phase (which could in some cases be as simple as downloading predefined/shared profiles).

[vascolp]

The configurations are saved on the remote because, at the time, PyBricks did not allow to save data on the hub. But now, beta only, it is already possible to save data on the hub.

However, the CityHub does not have enough space to have the Config Mode, it only has space for Play mode. Saving data in the Remote gives us a simple way of configuring a CityHub... through the usage of a TechnicHub...

Yes, the way to go is to have an external wysiwyg program to configure RemoteBlaBla. Probably as an APP in a smartphone... it would be nice to have an app in a smartphone to avoid the usage of the smartphone 

But I have no skills on android programming... nor time...... maybe on day.... 

[gyenesvi]

17 hours ago, vascolp said:

The configurations are saved on the remote because, at the time, PyBricks did not allow to save data on the hub.

Just to clarify, I meant that the (profile) data becomes part of the FW program, which is available already, not only in the next beta. I do understand however that that does not allow configuration without re-flashing the hub.

The external WYSIWYG config would have the advantage that only play mode would be required to be flashed onto the hub. I think it would be simpler to have a configurator from the web browser than a mobile app, then it would not be tied to any kind of platform/os, would work for anyone. And then we could avoid the usage of the smartphone.. instead just use a computer.. Is that a meaningful move? :)

But that needs to be learned as well, and I don't know such stuff either..

[vascolp]

8 hours ago, gyenesvi said:

...

In the documentation I have a little program that allows you to read or write the configuration (the profile if you want) of a remote.

The configuration is a simple string, like this: "RbEMs.AFBBiR.." which I call a BlaBlaCode. You can see an example of it in the video about the Zetros in the first post and another example in this mod.

The whole process is a bit clumsy, not very user friendly…  but it is easier than flashing FW each time you want to save a new profile.

The interface… I see what you mean, using a computer instead of a mobile... both would be very useful, I think. But yes, both require some knowledge and, ...time! 

[2GodBDGlory]

I was messing around trying to make a remote that could have more than two steps in each direction, and while I'm sure it's possible, I think it would be quite unwieldy.

However, in the process, I struck on a different geometry that works nicely enough for the two-position remote, but without illegal techniques or old space tires! It is a bit bulkier, and I think the feel of the remote is worse, but it might be a better option for some people:

It should be able to be reconstructed from the pictures in this gallery, should anyone be interested in trying it:

https://bricksafe.com/pages/2GodBDGlory/2-position-pu-remote-v2

[vascolp]

Couldn't resist to try it!

 

[2GodBDGlory]

Cool! That looks like a considerably simpler construction of the remote. Does it work well for you?

[vascolp]

It works well. In the left command, the tan pins sometimes seem to get a bit stuck in these: , while the right command has no problems at all. I suppose one has to get used to it.

[2GodBDGlory]

1 hour ago, vascolp said:

It works well. In the left command, the tan pins sometimes seem to get a bit stuck in these: , while the right command has no problems at all. I suppose one has to get used to it.

Nice! I wonder if this part would be any better than the tan pin:

 

[UltraViolet]

  I just got a couple of Keybrick One battery packs for my City Hubs so I can experiment without chewing through regular batteries.  Now I'm looking to clarify something about setting the remote configuration.  If I gather right from what you've explained in the documentation, the configuration for using a City Hub is actually stored in the name field of the remote control.  Am I able to rename the remote simply by using the Powered Up app to store an RBB configuration string, then disconnect the remote from the app and connect the remote to the RBB firmware'd hub?  I have loaded the RBB firmware on a City Hub and it seems to communicate with the remote, but errors out and drops the connection, suggesting a bad string.  Have I put an invalid configuration string in the remote (tried using the only two examples in the documentation), or am I doing everything wrong?  I'd really appreciate seeing some additional configuration string examples which would work correctly with the City Hub so I can get this functioning at all.  I would much rather have this working with the City Hub than any other hub model.  (I have flashed the latest firmware file directly, as I am aware of the PyBricks 3.2 compatibility issue.)

[vascolp]

Hi, thanks for trying it!

I suppose you can write the string to the hub using the Powered Up app, I never tried. You can certainly do it using the Pybricks Code  App, there is an example of small program to read and/or write the remote string in the documentation (section 9.5). But notice that, when you run  a program in current versions of Pybricks Code the program gets saved in the hub and the previous program stored in the hub is deleted. This means that, if you try it in a hub with Remote Bla Bla, you have to flash Remote Bla Bla again.... (I should mention this in the documentation... but I just noticed it while writing this).

After writing the configuration you want in the Remote, when you turn on the City Hub, you must have the appropriate motors previously connected to the hub. If the motors are not connected it might fail.

The configuration strings aren’t really easy to understand by a human, that’s why the idea is to define them with the help of  a Technic Hub. Anyway, here is an example. You should connect one motor to each port of the City Hub. Can be sensorless motors like the WeDo 2.0 Medium Motor or Technic Motors. Right button is a BLASimpleMotor and left button is a BLAStepsMotor. The string is:

RbAC..gABS....

Notice also the startup sequence:

1. On a completely disconnected hub, clicking the hub button should blink in blue (meaning you can now connect to the Pybricks Code app)
2. A second click will start Remote Bla Bla and the light should blink in white. You must connect the remote while the light is blinking in white. Turn on the remote by pressing the green button on it.
3. If the configuration string matches the connected motors, the lights on the remote and the hub should be steady green. 
4. Play.

Hope it helps!

Edited March 29, 2023 by vascolp