Do you mean a new topic in this category? Click on the category name ‘Cyberbrick’, and then click on ‘New Topic’ at the top of the list.
ah ok! it just popped up! Thanks!
1 Like
I do not have N20 (LA002), only the stuff that came with CyberBrick ultimate and beginner kits. I wonder if your wobbles are power supply related though, as the motor control is linear feed-forward PWM control from the value computational point w/o any feedback, thus no oscillations are to be expected. In comparison to original CyberBrick Core MicroPython code, I am using 100 Hz PWM frequency instead of the std. 50 Hz to drive the brushed motors though: CyberBrick_Controller_Core/src/app_espnow/rx/forklift/rxforklift.py at ce5e5dc4e9315175d34d180385ced8d7939609db · rotorman/CyberBrick_Controller_Core · GitHub
But that should make it even smoother.
Regarding possible CyberBrick supply battery voltage sampling/telemetry, I had further look of possible options with existing boards A11 (Core Module), X11 (receiver shield) and X12 (transmitter shield). Sadly, this is not possible without hw modifications, as the battery voltage (via voltage divider) is not wired to any of the ESP32-C3 pins.
The ESP32-C3FH4X on the CyberBrick Core has maximum of 6 analog inputs that can be mapped to GPIO pins 0 to 5 and 18 to 19. All those pins are already used on transitter X12 and receiver X11 shields, but theoretically if not all X11 servos or motors are used, then by adding a resistor divider circuitry limiting the voltage to 3.3V, it would be possible. The same applies for transmitter side battery voltage sampling - a sacrifice in one of the 6 analog inputs needs to be made in order to be able to sample the battery voltage.
Thus it would be possible, just not w/o any hw additions/changes and compromises.
Low battery warning could be signaled on the transmitter side e.g. with the on-board Core NeoPixel LED. One basic color channel for low transmitter battery voltage, another basic color channel for low receiver side battery voltage. Example: blinking blue could mean low batt on transmitter, blinking red - low batt on model and blinking blue/red - both batteries are low.
LOL! It’s probably the NeoPixel that’s dragging the battery down! 
1 Like
Good point. I’m running it on battery, but it hadn’t been charged for a while so hopefully that’s it. I’ll be able to test later today. If it’s still fluctuating, I’ll have to put a scope on it. Not convenient to do at my Summer residence…
@xrk, UPDATE: With the fully charged battery the N20 gear motor is behaving properly.
I just designed something that I think would work as an add-on and it’s made to use one of the analog inputs (on the transmitter shield) or maybe a cable hack on the Receiver. If I remember correctly, the ESP32-C3 needs the analog voltage to be between 0 and 2.5V so I have made a resistor divider with 4 identical resistors (eg. 10K)
Battery can be connected in one end, and the load (shield) in the other end.
I have ordered PCBs. Will release design files when tested and found to be working.
1 Like
If you make such a power meter adapter, please consider adding also current sensing that IMHO would also be interesting.
Thus why not add something to measure it as well and provide a voltage divider analog port for measuring battery voltage and a second analog port for measuring current as well. This is done very similarly in many higher end R/C models, e.g. PM02 V3 Power Module (12S) – Holybro Store
On X11 receiver shield, analog input is possible only on servo 1 to 4 control pins and motor 1 control pins, where although already HTD8811 is wired up. Thus realistic for an end user, w/o having to solder anything, is to only use the servo headers for injecting analog signal. Will work with custom MicroPython code, but not with stock CyberBrick app, as the default stock CyberBrick app does not support inputs (analog nor digital) on the receiver side/shield.
Yeah, that would also be nice to have, though to get a decent performance in the current range of a CyberBrick style vehicle, it’s a bit more elaborate than the simple voltage divider for the “fuel gauge” reading.
Personally I would probably go for a semiconductor solution with a small chip that handles most of it and maybe move to I2C for communications to the core. I know it’s not directly available on the shields, but it would open up for a bunch more sensors etc. and simple cabling (same type of connector but 4 pins, following qwiic/StemmaQT standard). I kind of did already add that connector on the Display Shield I designed.
1 Like
An alternative idea would be to create fully custom new Core board at least roughly with the same dimensions as the original and connecting pins matching the X11 receiver shield, but using a MCU with more I/O and adding the I2C 4-pin header there for expansion. Ideally going directly with support for CRSF/ExpressLRS RF comms. If not interested in manufacturing and selling self, could upload the files to manufacturers like JLCPCB, who also populate the boards, the users could just order the design there, w/o having to solder anything.
2 Likes
Out of curiosity I let the code from your post above to run on ESP32-DevKitC-V4 next to working CyberBrick remote and forklift flashed with my ESP-NOW code (that sends ESP-NOW telegrams roughly at 50 Hz) and unfortunately it does not show any packets.
By further tinkering and experimenting with it, I see that it only detects ESP-NOW telegrams sent to broadcast address (MAC FF:FF:FF:FF:FF:FF) and not directed ESP-NOW telegrams. In short, IMHO from the output of that ESP-NOW scanner code, or more the lack of it’s output, we cannot yet conclude that the original CyberBrick system also might not use ESP-NOW.
P.S. In order to build the code successfully, I had to change line 71 (see also here) to:
esp_now_register_recv_cb(esp_now_recv_cb_t(onDataReceived));
Updated my ESP-NOW code in CyberBrick_Controller_Core/src/app_espnow at espnowdemo · rotorman/CyberBrick_Controller_Core · GitHub to show how to control multiple models with it. Also added signal failsafe condition. The latter drives the outputs to a pre-defined state in case of a signal loss, e.g. when switching-over the remote to control another model.
The example files are especially tailored to official remote paired with official forklift and official truck, switching done via 3-way switch on the remote, similarly to original CyberBrick example code. But the code is by no means limited to those models nor also controlling only 2 models with it.
The MicroPython example is already prepared to switch between 3 models and can control theoretically unlimited amount of models, limited only by the free space available for the MicroPython code at the ESP32-C3 microcontroller file system on the CyberBrick A11 core module.
In comparison, the official CyberBrick MicroPython app supports switching/controlling only max. 2 models from the single remote.
With my custom MicroPython code it would also be possible to control multiple models simultaneously without switchover, e.g. left stick controls one model, right stick another, or any other combination of it. This also cannot at present day be achieved with the official MicroPython code.
If you want to test out the latest code version, be sure not to forget to add on the transmitter side code your CyberBrick receiver side MAC addresses into: CyberBrick_Controller_Core/src/app_espnow/tx/tx.py at 2b5f32c7c778b3b8427c4b743ec1f46c0796bec5 · rotorman/CyberBrick_Controller_Core · GitHub
1 Like
I’m inclined to switch the remote to a specific receiver only when starting up the remote. I like keeping the 3 way switch for model usage (eg, the turn signals on the truck) but I’m willing to use it one time on remote start up to choose WHICH device you’re connecting to.
Admittedly this does limit an scenario where one model could be controlled by the left joystick and another model by the right, but the three way switch doesn’t solve that implementation either.
You can easily change the behavior to the one you are after, just take:
out of the while loop and save the chosen model number into a variable that you are checking in the while loop afterwards. This way only the first sample of the 3-way switch picks the model and could be altered with a power cycle of the remote (or pressing the reset button on the Core).
Yeah, that was my plan. Among other changes.
1 Like
I grabbed the old trusty Texas Instruments CC2540 dongle I had lying around and used TI SmartRF Packet Sniffer app in BLE mode, while having two CyberBricks paired with default BambuLab/MakerWorld MicroPython code and comms running in the background. Did not see any BLE telegram in the sniffer log, other than the dongle’s own advertisments. Next opened a CyberBrick app on an Android phone and connected to one of the CyberBrick, while the sniffer was running, and also could not see any BLE telegrams being exchanged by the CyberBricks. From this it seems the original comms between the CyberBrick transmitter and the receivers in the models are not via BLE.
On another note, made a PR against main CyberBrick Controller repo with my ESP-NOW additions: Added an ESP-NOW alternative to control CyberBrick models. by rotorman · Pull Request #4 · CyberBrick-Official/CyberBrick_Controller_Core · GitHub
The code works and works according to my tests robustly, but surely there must be numerous segments that can be improved algorithmically or generally from the way the code is structured (I am still new to MicroPython, started fumbling with it just couple of weeks ago, as I got my CyberBricks delivered). Happy to hear about improvement ideas.
1 Like
For the interested, I added ESP-NOW control code also for the Bulldozer by MottN. The code can be downloaded from: CyberBrick_Controller_Core/src/community/app_espnow/rx/bulldozer at espnowdemo · rotorman/CyberBrick_Controller_Core · GitHub
With the custom MicroPython ESP-NOW code, I can now control 3 models from single remote, switching via 3-way switch: forklift, truck and bulldozer.
3 Likes