dwalton76

FYI all of the spi strings are defined: ddwalton@ddwalton-mbp[_platform]# grep spi *.py brickpi3.py:OUTPUT_A = 'spi0.1:MA' brickpi3.py:OUTPUT_B = 'spi0.1:MB' brickpi3.py:OUTPUT_C = 'spi0.1:MC' brickpi3.py:OUTPUT_D = 'spi0.1:MD' brickpi3.py:OUTPUT_E = 'spi0.1:ME' brickpi3.py:OUTPUT_F = 'spi0.1:MF' You can import them via from ev3dev2.motor import OUTPUT_A, OUTPUT_B, OUTPUT_C Same goes for the INPUT strings So the motor_a, etc objects that you are creating are not going to be used by MoveTank, MoveTank is going to create its own LargeMotor objects. So what you have above will work but this is going down a path that could be very confusing to troubleshoot later :( Something like the following would be much cleaner wheel_a = MoveTank(OUTPUT_A, OUTPUT_B) wheel_c = MoveTank(OUTPUT_C, OUTPUT_D) wheel_a.set_polarity(LargeMotor.POLARITY_INVERSED, [wheel_a.left_motor,]) wheel_c.set_polarity(LargeMotor.POLARITY_INVERSED, [wheel_c.left_motor,]) brickpi cannot auto detect the sensors so you have to use set_device() to specify what is connected on what ports. I don't have a code example handy but if you search in the ev3dev-lang-python repo for set_device() you should be able to find an example (there may be an example in the docs also...not sure). Can you post the code you are using where the motors go beserk?

from ev3dev2.motor import MoveTank, OUTPUT_A, OUTPUT_B, LargeMotor, SpeedRPM robot = MoveTank(OUTPUT_A, OUTPUT_B) robot.set_polarity(LargeMotor.POLARITY_INVERSED, [robot.left_motor,]) This should do the trick. The second argument to set_polarity() is a list of motors that you want to change the polarity for.

You can pass set_polarity() a list of motor objects to tweak

So MoveTank inherits from the MoveSet class, MoveSet has a set_polarity() method, that will do what you want.

That is weird...it is like they are fighting each other. If you remove the big black gear connecting them does that make any difference? (just as an experiment). MoveTank is the way to go though, it will start the motors as close together as possible.

Something to try would be to git clone https://github.com/ev3dev/ev3dev-lang-python and then set your PYTHONPATH env variable to point to that repo. I'm not sure if the stacked brickpi support is in the released images yet but if you git clone ev3dev-lang-python that will put on on the latest and greatest which has it.

If you are running ev3dev then you can completely ignore the dexter industries brickpi images, docs, etc. Think of ev3dev as a complete independent alternative to raspian, the dexter industries OS, etc. In a nutshell just follow this guide :) https://www.ev3dev.org/docs/getting-started/

I haven't tried it yet but OpenCV is supported in python3 now. Agreed on the statement of not attempting to run OpenCV on an EV3...it is painfully slow :( Offloading to pi3, laptop, etc is well worth it.

Some info here: https://www.dexterindustries.com/BrickPi/brickpi3-technical-design-details/ the dexterindustries forums are fairly active (employees will respond to questions you post), it may be worth starting a thread there to ask about your specific setup.

FYI there are some really good ev3dev python docs here: https://sites.google.com/site/ev3devpython/ The author is looking for feedback on the site, please post here with any feedback: https://github.com/ev3dev/ev3dev-lang-python/issues/511

Try “sudo pip3 install requests” to get that module installed

I broke the "support EV3 protocol" issue up into two issues, one to implement client support and one to implement server support: EV3-to-EV3 protocol: client support for daisy-chaining EV3-to-EV3 protocol: server support for daisy-chaining It would probably be best to start with the "client support" issue. A large chunk of that code is already written in another repo and you could test it by trying to control a stock EV3.

If you have software dev experience python is pretty easy to pick up...it is very readable. I did some digging and found a repo on GitHub where someone has already implemented the EV3 protocol in python...so from their laptop they can control an EV3. This part we should be able to bring into the ev3dev python library without a crazy amount of work. What is missing is the code to implement the server side of the protocol. So if you want to take an EV3 and use it to control an ev3dev that code has not been written (not that I have found at least).

You can stack up to four brickpi3s on a single pi3 :) Support for this just went into ev3dev-lang-python about a month ago so you may need to clone the repo to run the latest and greatest. You can see the port names for the stacked brickpi3s here: https://github.com/ev3dev/ev3dev-lang-python/pull/562/files In terms of motor multiplexors I am not sure which ones are supported on ev3dev off the top of my head. I am sure there are some that are but I have never tried to use any of them. Another option is to do a physical multiplexor: I used this several years ago to combine an EV3 with an excavator to make it remote controlled. I needed to be able to control six movements with just four motors: In hindsight I should have used a smaller turntable that would have made it easier to fit everything. yep you can name the brick whatever you want. ev3dev is just debian linux so anything you can do in debian you can do in ev3dev. If you do not go the route of stacking brickpi3s and decide to do "setup communicatino between multiple bricks" come on over to ev3dev-lang-python and I can assign https://github.com/ev3dev/ev3dev-lang-python/issues/385 to you :) We are always looking for new contributors and it sounds like you have a legit use case for that feature...it would be awesome if you implemented that one.

I use this one: https://www.amazon.com/Raspberry-Pi-WIFI-Adapter-Dongle/dp/B009FA2UYK/ref=sr_1_fkmr0_2?ie=UTF8&qid=1542755291&sr=8-2-fkmr0&keywords=pig+hut+wifi It isn't as compact as an EV3 but a pi3 + brickpi3 + this screen: https://www.amazon.com/gp/product/B01N447AEY/ref=oh_aui_search_detailpage?ie=UTF8&psc=1 makes for a nice alternative, it boots in about 8 seconds!! I put a SSD on it once and the boot time was even better :) (I forget exactly how fast it was though)