EV3 / NXT vs PF in Technic vehicles

[mvshabeer]

Do anyone use EV3/Nxt motors?

I have EV3 and have no PF elements. I tried to motorize (drive/steering) the 42029 with EV3 but feels like there is no space. Also the EV3 brick itself adds lot of weight.

I bought ev3 to make the vehicles I build to be intelligent. This way I think I can only use EV3 for something that sits on the table rather than moving :(

I am considering buying whole set of PF

1x servo

2x XL motor

1x L motor

1x M motor

2x IR reciever

1x IR Remote

1x Speed remote

1x Battery box

This almost cost $150.

Do you guys have any tips to use EV3 with Technic (vehicles) and hence minimize the PF elements purchase

Thanks

Shabeer

[darksheep]

HI

There is one way to do this , you could use the EV3 to send IR commands to the PF IR receiver.

That way you would have a smart controller .

You would need some thing like this

One think I am looking at doing is using EV3 with a Sbrick , but I don't know if it is supported or if it will work. Will have to wait till i get one .

[MajorAlvega]

SBrick works fine with the EV3 but you need a Bluetooth 4.0 USB Dongle and ev3dev (the EV3 has only BT2.x inside, doesn't talk with the SBrick, and at the moment LEGO firmware isn't flexible enough so you need a microSD card with ev3dev - a Debian Linux for EV3).

But you just need PF IR + HiTechnic or SBrick if you want the EV3 outside of your model.

If you want the EV3 inside of your model and just need 4 or less motors, you can use an adapter cable to connect PF motors to it. LEGO had a NXT>RCX adapter, if you get one you can add a PF extension cable to connect to the PF motor. Or you can make your own cable with just a few resistors.

As NXT/EV3 motors are servos, you don't need the PF servo. The smaller EV3 motor can replace it.

Now if you want the EV3 inside you model AND need more than 4 motors... you may:

- use a LEGO WeDo USB Hub to connect 2 PF motors (again, you need ev3dev) but as USB is only 5V (and perhaps 0.5A) motors will have less power - not much of a problem because if you want to use a EV3 you don't expect a race car, you expect a slow rover

- use PF IR and HiTechnic to add 2 PF motors with IR link

- use SBbrick and USB BT4.0 dongle and ev3dev to add 4 motors with BT link

- use another EV3 in daisy chain to add 4 motors (overkill!)

Lots of options... neither of it cheap. Lots of cables also and big geek factor.

Edited December 3, 2014 by MajorAlvega

[miguev]

You just made my day! I was finding myself unsatisfied with the limit of just 3 motors on the EV3 and thought about controlling an SBrick from the EV3. Been putting off looking into it with the pessimistic assumption that the would not be supported by ev3dev... You prove me wrong, you make my day :)

[MajorAlvega]

Well, it is not «supported» by ev3dev in the sense that there is a driver like there is for the Color Sensor of for the Servo Motor and very recently even for the WeDo... but as long as you can use shell scripting or any language that can invoke system commands (in particular the command «gatttool» from BlueZ 5.x) you are OK.

SBrick is still at the very beginning. It will have an API or an SDK or something like that but not now - the software guys are focused on the iOS/Android/Windows Phone client app and the hardware guys are almost delivering it to production, pehaps even as we speek (see those last posts at SBrick forum).

There is also no good library (as far as I know) for Bluetooth 4 Low Energy - the best I've found is bluepy but I could not make good use of it yet. So, at the moment, my use of gatttool is the only known way to talk to SBrick. It's enough for most needs but not for all - if you need very low latency and very high frequency I'm sorry but you'll have to wait. But if its enough for you to send ~ 10 commands per second and get a response in the next second... you can do it right now (at least from EV3 with ev3dev, from Raspberry Pi with an upgraded Raspbian and from Ubuntu).

[mvshabeer]

Thanks for the quick responses

either way I might need PF motors

I just did a test to see how the 2 coupled EV3 large motors drive the 42029. Even with 2 motors connected to the rear drive it's really slow and no enough torque.

Do 2 XL motors give better performance.

[MajorAlvega]

Better speed yes, better performance perhaps not.

You should see Philo's excelent "LEGO® 9V Technic Motors compared characteristics". The Power Functions XL motor has more or less the same torque as the EV3 large motor but a bit more speed. If you want a bit more speed go for the L Motors. Much more speed and still some torque AND still commercially available only the PF train motors (not commercially availabe there is the Technic RC motor, good luck finding it at bricklink at a good price).

But you said you want your vehicles "build to be intelligent". As the EV3 is not a supercomputer, any «intelligence» costs time so speed [usually] is not a great concern for those who build autonomous vehicles with the EV3.

[miguev]

A driver would be nice, but invoking gatttool would be enough for now. High latency / low frequency would be a problem for many applications, but which latency is high?

I'm not sure what you mean by getting a response from the SBrick, when does the PF element move?

I mean, if I sending a command with gatttool to (e.g.) move a PF Servo 90º/100% to one side, how long does it take to start moving?

Does the response from the SBrick come back only when the servo reaches the destination position?

Uh, 4 lines, 4 questions, I can do with a big cup of RTFM

[MajorAlvega]

The servo moves almost imediately. By almost perhaps in 0.3~0.5 seconds, I don't have a good way to measure. I'm trying some improvements in my method, hope to get slightly better latencies but you don't want to make heart surgery with it :)

The SBrick response, in bluetooth terms, doesn't come in sync with the movement. It doesn't matter if you just send one command (like move servo to 50%) but I can't send another command until this acknowledge comes (well, I can but it stays in a queue - not a SBrick queue, more like an operating system or python queue). So no "bursts" - the above video with the running PF lights can be a little faster but not much more. and when I stop the programm (Control-C) lights keep running one second more (the queue is beeing flushed).

Edited December 3, 2014 by MajorAlvega

[miguev]

Oh, that queue sounds problematic, ideally you should be able to cancel commands that have been obsoleted by newer ones.

[MajorAlvega]

We're getting out of topic, we should continue this on other topic (but I assure you it is not a SBrick problem, just a programming problem from someone who is not a programmer, just a copy&paster).

Returning to the topic, I think you gonna like this video:

it's an example of "Power Functions Remote Control Sensor" from the site nxtprograms.com, where they show how to mix PF IR remote with the NXT (the same applies to EV3).

Edited December 4, 2014 by MajorAlvega

[miguev]

Yeah, sorry for deviating the conversation, and thanks for the video! I anticipate I'll get an EV3 for Xmas and can't stop thinking of near-real-time applications

[mvshabeer]

We're getting out of topic, we should continue this on other topic (but I assure you it is not a SBrick problem, just a programming problem from someone who is not a programmer, just a copy&paster).

Returning to the topic, I think you gonna like this video:

it's an example of "Power Functions Remote Control Sensor" from the site nxtprograms.com, where they show how to mix PF IR remote with the NXT (the same applies to EV3).

Interesting, but I didn't got how it's possible to control drive/steering and 3 weapons with 1 remote

[John Daniels]

Interesting, but I didn't got how it's possible to control drive/steering and 3 weapons with 1 remote

I would say that he used the multiple channels on the PF remote. You don't see him driving and deploying the weapons at the same time because he has to flip the channel switch.

~John

[MajorAlvega]

Well, you can see 2 IR receivers over the tank so the same remote can be used with 2 different frequencies to control 4 channels. Drive and steering need 2 channels so the other two are probably used to simulate two touch sensors.

Two inputs mean 4 combinations:

0 + 0 : no action

0 + 1: weapon 1

1 + 0: weapon 2

1 + 1: weapon 3

There's also the possibility to use a sequence of inputs, like morse code:

short short short: weapon 1

short short Long: weapon 2

et cetera