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)

I am one of the maintainers of https://github.com/ev3dev/ev3dev-lang-python , I will try to watch this post in case you have any questions about the python library.

There is an issue open for this here: https://github.com/ev3dev/ev3dev-lang-python/issues/385 But nobody has worked on it yet. It is still possible to have multiple ev3dev bricks communicate with each other though, you just have to do some client/server coding in python. I do a lot of work on ev3dev-lang-python, there is a small but pretty active group of contributors for it. We have a separate repo of demo programs for some of the more popular builds (see https://github.com/ev3dev/ev3dev-lang-python-demo ). There are demo programs for: BALANC3R EDUCATOR EV3D4 EV3RSTORM EXPLOR3R GRIPP3R MINDCUB3R R3PTAR TRACK3R Another good option (if you have one) is to use a raspberry pi3 with a brickpi. I do most of my dev on that just because it is so much faster than an ev3.

One challenge is I just finished the LDD file and have never built the robot from that file, so I am sure I probably made a few errors. If I use blueprint to build a detailed set of instructions (where I make edits to undo "pins in the air", etc) but then find that I missed a part and have to update the LDD file won't I have to start over again in blueprint? I have a friend building it now via the LDD file so I should know soon if I missed anything. This is the robot I am trying to create better instructions for, it solves 2x2x2 up to 6x6x6 rubiks cubes: https://www.rebrickable.com/mocs/MOC-12712/dwalton76/cranecuber/#mocs Agreed, thank you @msx80 blueprint is some cool software. It would be cooler if it were open source but I'm guessing you've been asked about that before :)

Glad to hear the virus is a false alarm :) I gave it a try and it looks pretty cool. My build has 1013 parts split into 9 groups. I found that instructions are doing two odd things: it tends to have a lot of pins floating in midair and then a few steps later it will place a beam around those pins there are a lot of steps where I cannot see the part being placed My gut says I just need to break the build down into more than 9 groups. What is a typical/recommended number of groups to use for a build with ~1000 parts?

From doing some reading here my take on this project is: latest windows download is v26 which was uploaded on May 2017 (per the edit timestamp of the first post) v26 has a virus (see https://bitbucket.org/msx80/blueprint/issues/124/virus-in-blueprint0026zip) the source is closed the project is no longer actively maintained I am not trying to be negative I am trying to figure out if this is something I can use/contribute to, are my bullets above an accurate assessment of the state of things?

I bought one and told my wife to give it to me for x-mas

Thanks! As soon as I had the idea I knew that alien from toy story would have to be the picked up :) I went through a couple of different approaches on the multiplexer. The other one I tried was cool because it would let you turn on two outputs at once but it was just too big. http://programmablebrick.blogspot.com/2013/09/lego-technic-two-input-four-output.html

I recently combined an EV3 with a 42006 Excavator to make it fully remote controllabe. I put together a video of it in action: Here is a blog post I did on it with links to the instructions and EV3 code: http://programmablebrick.blogspot.com/2013/09/remote-controlled-ev3-lego-excavator.html It was a lot of fun but figuring out how to build a motor multiplexer small enough to fit in there was tough.