Several questions:
I see broadcast examples for setting a motor’s speed, e.g. MA100, and for position, e.g., MAP180. Works great.
But how do I do a position command at less than full speed, i.e., Motor A at 50% speed to position 180?
Tried to simulate this in a loop, i.e., run the motor at low speed, watch the encoder value and stop when I get to the right position. But couldn’t get the encoder value dynamically. So:
How do I read the encoder value for Motor A? (Seem to be running into a “have to broadcast once to the sensor before reading a value” bug?)
While I’m at it, saw various motor control messages, mentioning PID controllers, etc., but appeared to be for the Python interface. Any of these available in the Scratch environment. Which leads to the following question:
I suspect the only “official” doc for the BrickPi Python API is the code itself. So I’ll go look at it. Is it possible to get at all the functionality in this API by doing “broadcasts” from Scratch? That is, is the Scratch API just a thin shim that marshals the text string argument from the Broadcast and conveys it to the Python API, and suitable return?
TIA,
Mike (attempting to use BrickPi for teaching robotics to kids
Not currently possible to do both position and speed control at the same time from Scratch. Looked at the BrickPi3Scratch.py file, which contains the Scratch BrickPi3 command interpreter and calls the appropriate function in the Python API. But I could modify this file, and add a new motor speed command which combines speed and position params. Also looked at the Python API in the file in the brickpi3.py file. Here the set_motor_… functions look useful, in particular, set_motor_limit which I presume will allow me to set a speed limit for a subsequent set_motor_position call. Comments from the experts?
There’s a syntax for this on the Scratch command cheatsheet, BrickPi3_Scratch_Commands.png, an essential guide. Haven’t tested it yet though.
no info on this yet
OK, it’s the brickpi3.py file. And the translation from Scratch Broadcasts to this API isn’t a “thin” shim, but can be groked.
Scratch is simple and intended to be used by beginners. It supports the basics, but does not give full access to the functionality that Python and C++ offer.
In Python, you could do something like this:
# reset motor A encoder (set the encoder count to 0).
# Usually you would do this once at the beginning of the program.
BP.offset_motor_encoder(BP.PORT_A, BP.get_motor_encoder(BP.PORT_A))
# set motor A power limit (in percent) and speed limit (in Degrees Per Second).
# Set either one (or both) to 0 to disable the corresponding limit.
BP.set_motor_limits(BP.PORT_A, 50, 200)
# run motor A to 180 degrees.
BP.set_motor_position(BP.PORT_A, 180)
In my case, I do need to get access to this extra functionality from Scratch. So I’ll go ahead and make local changes to the BrickPi Python support files using your suggestions.
Will close this thread as soon as I can verify the changes.
OK, tried out set_motor_limits(BP.PORT_A, 50, 200) and variations. The second parameter, power limit, does work. But the third, to set an angular speed limit, has no effect. Or, at least, not the right one. Reasonable values don’t seem to have any effect, except for very small ones, e.g., 5, for which the motor won’t move at all.
Is this a bug? What are “reasonable” values for the deg/sec limit? Is there possibly a hardware/firmware problem?
It sounds like you might be running an older version of firmware that didn’t yet support the DPS limit. Try updating the software (on Raspbian for Robots run the DI Update) and then the firmware (can also be done with DI Update).
Then run sudo python ~/Dexter/BrickPi3/Software/Python/Examples/Read_Info.py and make sure the firmware version is 1.4.6 (latest version as of writing this).
To test to be sure the speed limits are working, run this example programsudo python ~/Dexter/BrickPi3/Software/Python/Examples/LEGO-Motor_Position.py. As you manually rotate motor D, motor A should follow it. Note that the limits will keep motor A from running as fast as it would otherwise (it won’t go over 50% power, and it won’t exceed 200 degrees per second).
Matt, wow! We don’t have the current version of BrickPi3 firmware on the onboard Arduino. Here’s the report I got (after updating my Raspbian image to your 2017.10.05 version, in case it was that software which was obsolete.)
pi@dex:~ sudo python ~/Dexter/BrickPi3/Software/Python/Examples/Read_Info.py
Manufacturer : Dexter Industries
Board : BrickPi3
Serial Number : 8250A6D2514D32384E202020FF12163F
Hardware version: 3.2.1
Firmware version: 1.4.0
Battery voltage : 11.724
9v voltage : 9.144
5v voltage : 4.999
3.3v voltage : 3.313
pi@dex:~
Where can I find the current version of firmware? I was also confused because the only version I could find was on Github (https://github.com/DexterInd/DI_Arduino) and appeared to be 1-3 years old, older than the hardware we have. Hmm… I’m obviously missing something here. Any guidance would be appreciated.
Is this correct, Matt? Can I insure that I stay up to date on the BrickPi3 software by syncing to this repo?
It looks like the older repo contained Arduino source code, but the new one only contains binary versions of that firmware. Is it now the case that the new Arduino code is not open source, but proprietary? Is there a current document that describes the licensing status for all the BrickPi components, hardware, software and firmware? (We want to be careful about respecting IP rights.)
Thanks,
Mike
PS: Will load firmware v. 1.46, try the set_motor_limits test and report back here.
Bingo! Finally succeeded in upgrading the BrickPi3 firmware to v. 1.4.6. Your test case works as advertised, i.e., moving motor D fast manually through approx. one-half revolution causes motor A to follow slowly, but with the full final rotation. Looks like this fully addresses my original question, so we can close this thread.
BTW, part of my problem updating the DI software using your automated tool was due to network issues, initially with IP address assignment over an Ethernet VNC connection to my MacBook (used as monitor and keyboard) and then over WiFi for the firmware download. Couple suggestions:
It would really be great if your standard RPi image included a DHCP server which would automatically supply an address to a device connected to the eth0 port on startup. This would make it much easier to use a laptop on a wired Ethernet connection as the console for the RPi.
Please have your website updated to remove links to obsolete information, especially links to obsolete repositories and software versions.
The BrickPi3 uses a single ARM processor, rather than the two Arduino/AVR processors on the BrickPi+.
The BrickPi3 firmware source code is closed source (the source code is not available).
The BrickPi3 license file is located here. Note that even though the firmware is mentioned in the Software License section, the license applies only to what is released (available in the BrickPi3 repo).
Typically the Raspberry Pi Ethernet would be connected to the LAN (router), and would get assigned an IP address from your LAN DHCP server. This way the RPi has internet access (for updates) and LAN access (so you can connect to it from e.g. a laptop on your network). If you plug it directly to your laptop, you will need to manually assign IP addresses, and for the RPi to have internet access, you would need to set up a network bridge on your laptop.
