New Power Functions ideas

[allanp]

We really need a proportional servo, which means if you move the stick a little, the motor moves a little. When you release the stick the motor moves back to it's original position. Perfect for controlling steering, gearboxes, pneumatic valves and so on.

[le60head]

Thanks for the description. I agree, proportional servo would be a good addition!

Rubber bands or springs don't always do the trick, and they occupy to much space, which is a pain usually.

There is such a motor in the RC Buggy receiver unit - the built in motor for the steering is with 3 steps and returns to center when you release the control stick on the remote. I am not aware of TLG making a proportional servo available in any other situation.

[allanp]

Yes that's the kind of motor i'm talking about, but hopefully with more than 3 steps.

[Lucas]

@le60head

that makes no sense... you need the new remote and receiver to get the extra channels.

Actually newer (current) RC receivers support 8 channels (16 functions). But they dont have a switch for additionals 4 channels and RC controllers support only 4 channels. IMHO it is managable to control 16 functions from Mindstorm using IR link. I dont have Mindstorm (im waiting for next generation) so Im not able to prove it.

[DLuders]

TLG should consider the Lego-compatible motor & servo motor adapter kits sold on Inanimate Reason's website. If folks don't mind that the parts don't have "Lego" written on them, you can buy them right now:

[Blakbird]

YES YES YES YES YES!!!!!!!

Radio waves are sooooooo much better than infrared waves! The funny thing is im learning about this stuff in my Chemistry class, who would have though school is helpful! .

My guess is that the reason they did not use radio is because many countries regulate the use of radio waves and acceptable frequencies. Since LEGO is a highly international product, it would be difficult to come up with something inexpensive that could be sold everywhere.

[timslegos]

My guess is that the reason they did not use radio is because many countries regulate the use of radio waves and acceptable frequencies. Since LEGO is a highly international product, it would be difficult to come up with something inexpensive that could be sold everywhere.

Ohh i that makes sense. So the acceptable frequencies in America are different than in other countries. Thats a shame

tim

[zewy623]

how about a high speed and high torque motor, since the xl is slower than the m (and much slower than the e-motor, for those of you who know about it) like lets say i want my unimog to have speed, but using the m motor wont work because of lack of torque on such a big vehicle (and wont work with the e-motor, since it has virtually no torque)

so i say high speed/high torque motor

[timslegos]

how about a high speed and high torque motor, since the xl is slower than the m (and much slower than the e-motor, for those of you who know about it) like lets say i want my unimog to have speed, but using the m motor wont work because of lack of torque on such a big vehicle (and wont work with the e-motor, since it has virtually no torque)

so i say high speed/high torque motor

I would totally agree with you! Although the old r/c buggy motor has super high rpms and a good amount of torque too.

tim

[zewy623]

@tim

ok so the old buggy motor had one, but what about people who are just startin out with technic (like me) so why not just make a new one anyways, if there is going to be a rock crawler next year as the flagship, they have to create some high torque and high speed motor if its rc

[Sokratesz]

how about a high speed and high torque motor, since the xl is slower than the m (and much slower than the e-motor, for those of you who know about it) like lets say i want my unimog to have speed, but using the m motor wont work because of lack of torque on such a big vehicle (and wont work with the e-motor, since it has virtually no torque)

so i say high speed/high torque motor

Uhm...you realise that having an XL motor with higher speed and same torque would mean it drawing an insane amount of power, right?

- Sok.

[KEvron]

an insane amount of power

then there are liability issues to consider, with regard to property damage and personal injury. they probably wouldn't want to make toys powerful enough to remove digits.

KEvron

[Milan]

then there are liability issues to consider, with regard to property damage and personal injury. they probably wouldn't want to make toys powerful enough to remove digits.

KEvron

I think Sok meant that such a motor would drain very much power (from battery).

[Parax]

Servos and proportional remote controller.

Yup I'd vote for a servo too! (did someone say cuusoo) Perhaps 90 Degrees Left or right (180 total) This 'could' be controlled using the the existing PF system with 7 steps each side allowing position control from the dial remote or full 90 degrees from the on/off levers remote. I doubt this would happen because the 'signal' wires carry pwm power, but it would be possible.

My guess is that the reason they did not use radio is because many countries regulate the use of radio waves and acceptable frequencies. Since LEGO is a highly international product, it would be difficult to come up with something inexpensive that could be sold everywhere.

Hopefully one day Bluetooth (or alt.) will be cheap enough to make this a reality!

P.

Edited November 16, 2011 by Parax

[KEvron]

I think Sok meant that such a motor would drain very much power (from battery).

yes, i got that. another consideration lego might have, aside from drained batteries, is their own position of liability in releasing a toy which is potentially dangerous. were i a toymaker, the latter would likely provoke a greater concern.

KEvron

[freakwave]

Interestingly this question on the extra channesl for PF popped up over at 1000steine as well.

I support the idea of having more than 4 IR channels for PF. But it should definately be compatible with the existing IR receiver and remotes.

Actually newer (current) RC receivers support 8 channels (16 functions). But they dont have a switch for additionals 4 channels and RC controllers support only 4 channels. IMHO it is managable to control 16 functions from Mindstorm using IR link. I dont have Mindstorm (im waiting for next generation) so Im not able to prove it.

The question rose because if you remote control a small trainlayout with a few extra functions you hit 8 possibilities pretty fast. For my special use case we had at a recent exhibition, Bricking Bavaria, two Monorails on our Moonbase. Those were running through PF-IR Receivers and we used the NXT to control station entry, stopping and resuming the journey, looked really really great. Now here comes the catch, another guy was showing nearby his roboter and sometimes we wondered why our MRs just stopped (even if the time-out of the PF-accu did not apply). Reason was he was using the same channels of course.

Now to fast forward to Lucas' statement. It is right, from PF Protocol V1.10, dated Oct.28th 2009, onwards you have the possibility to control an additional 4 channels giving you 16 outputs! And yes, it works and I could already get it to work by myself.

How to get it to work?

IR-Reiceiver

First of all you need a IR-Receiver compatible with the new protocol. Given that it was release around third quarter 2009, the IR-Receivers should be produced since then. How to spot them? Good question! At the bottom they have a stamp like "16K1" or "40K7". I posted this to LEGO support as well, but I still lack a (proper) response. Here's my theory: I have four receivers, three have an end-digit of "7" or "8", one has a "1". Only the one with the "K1" works, so it must be new (post 2009).

-> first two digits: production week

-> digit three and four: Production year K7=2007, K1=2011,...

My theory might not be complete as I have heard of digit on and two being also "62"...

enough on that.

IR-Protocol

There is a bit in the protocol called "address". It was described in V1.0 as "Extra Address Space", but given no further use, apart from mentioning that it needs to be "0" for "current" receivers.

Looking into the PF Protocol V1.10 on page 7 there is an explanation of the "Extended Mode" and how to get there using the Toggle Address Bit command.

The limitations you need to be aware are that:

- once an IR-Receiver is switched to the Extra Address Space it cannot accept commands from the usual LEGO remote controls anymore. Those work on the lower address range.

- once the IR-Receiver is powered off and on again, it will be in the lower address range allowing it to be controlled with standard equipment.

How to switch and send commands in the Extra Address Space?

The easiest way is to use what LEGO and approved suppliers have available, notably the NXT and a HiTechnic IR-Sensor. Other sensor may do the job as well.

Now out of the box HiTechnic can only do the standard things the IR-Remotes of LEGO can do. Using NXC there is a possibility to send "raw" data to the IR-Sensor making it send basically what you tell it to send.

So you can build your switch command (for channel one set with the orange switch) like:

HTPFRawOutput(S1,0x07,0x00,0x06);

From now onwards the IR-Receiver does not react to the remote set to Channel 1. Everything needs to have the "Address Bit" set. So you can send another raw command like:

HTPFRawOutput(S1,0x00,0x0c,0x07);

to get full speed forward on the red output (Output 1)

How to make this more user friendly?

I am in contact with Gus from HiTechnic who provided me a modified NXT-G block to control the switch over and the motors in an easy way (Thanks a lot!). The block works perfectly and we are just discussing how to properly implement this extra address space activation without too much hassle for the user.

Final verdict:

I think this offers great possibilities especially for exhibitions where you want to have certain moving things keep moving and not be prone to other PF-Remotes. Additionally a really big MOC with, may be individual lights, compressors etc. might also call for more that 8 controllable channels.

The only disadvantage is the reset after power off, however that can be overcome in an fairly easy fashion when using teo power supplies, one for the "Extra Address Space" receivers and one for the common address space. Then simply switch on the extra ones first, put them into the correct mode and start working.

Well a lengthy post but hopefully it helps you!

[Lucas]

IR-Reiceiver

First of all you need a IR-Receiver compatible with the new protocol. Given that it was release around third quarter 2009, the IR-Receivers should be produced since then. How to spot them? Good question! At the bottom they have a stamp like "16K1" or "40K7". I posted this to LEGO support as well, but I still lack a (proper) response. Here's my theory: I have four receivers, three have an end-digit of "7" or "8", one has a "1". Only the one with the "K1" works, so it must be new (post 2009).

-> first two digits: production week

-> digit three and four: Production year K7=2007, K1=2011,...

My theory might not be complete as I have heard of digit on and two being also "62"...

enough on that.

There is a really easy method to say if IR-receiver support new protocol. Receiver has a little green LED to indicate power-on state. When one switchs on power to new receiver the LED blink once and than turn on. LED don't blink on old receiver.

How to make this more user friendly?

I am in contact with Gus from HiTechnic who provided me a modified NXT-G block to control the switch over and the motors in an easy way (Thanks a lot!). The block works perfectly and we are just discussing how to properly implement this extra address space activation without too much hassle for the user.

The easiest way is to use 4 old and 4 new receivers. NTX program just send a command to switch to extra address in startup. Old receivers will ignore it and new ones will be switched. Now you have 8 channels.

[mostlytechnic]

THANK YOU for that info on the extra channels. I've even READ the protocol and somehow missed that ability. Totally going to use it for my arduino-controlled train remote, so then I'd still be able to use normal remotes to control another bunch of stuff :)

edit: re-read the protocol...

You don't actually get 8 more outputs this way. You get 4 plus 4 "sort-of" outputs. Basically on each of the 4 new channels, output A is regular PWM (almost - you can only do speed up, speed down, and brake. No float, no direct setting of the speed like you can on a normal channel. Basically it recreates the speed remote). On output B, you only have forward and float. No reverse, no speed control, no brake. So that'd be good only for turning something on and off - lights, for example. Not running a vehicle or anything else where you need control.

So, to use this on my arduino-based train remote, I've got quite a bit of new programming to do. I was only planning to run 3 trains, so this will be enough to handle the trains and leave the full 8 normal outputs for other uses...

Now to actually use this though, assuming you want some receivers in extended mode and some in normal, I guess you need to have all the normal ones turned off (or covered) when you send the "go to extended mode" command, and then you can turn on the normal ones, right?

Edited November 17, 2011 by mostlytechnic

[JopieK]

THANK YOU for that info on the extra channels. I've even READ the protocol and somehow missed that ability. Totally going to use it for my arduino-controlled train remote, so then I'd still be able to use normal remotes to control another bunch of stuff :)

We should make a wiki for that or something. I also came up with a name LEGuanO :)

Currently I do research with students on RF control of LEGO trains with PF.

[Lucas]

You don't actually get 8 more outputs this way. You get 4 plus 4 "sort-of" outputs. Basically on each of the 4 new channels, output A is regular PWM (almost - you can only do speed up, speed down, and brake. No float, no direct setting of the speed like you can on a normal channel. Basically it recreates the speed remote). On output B, you only have forward and float. No reverse, no speed control, no brake. So that'd be good only for turning something on and off - lights, for example. Not running a vehicle or anything else where you need control.

You are confusing extended mode with extra address space. These are two different things. Extra 4 channels should be fully functional as first 4 channels. You can also use Combo direct, Single pin continuos, Single pin timeout and Single output modes for extra channels.

[freakwave]

You are confusing extended mode with extra address space. These are two different things. Extra 4 channels should be fully functional as first 4 channels. You can also use Combo direct, Single pin continuos, Single pin timeout and Single output modes for extra channels.

Lucas is right, the "address" bit is available in each of the commands. So you can use those commands also for Channels 5 - 8. I used it in my sample command (Single Output Mode) for channel 5 (HTPFRawOutput(S1,0x00,0x0c,0x07);)

The use of the Extended Mode command escapes my reckoning...Looks to me like they had some spare space and just got functions in...

fW

Edited November 17, 2011 by freakwave

[mostlytechnic]

Thanks for the correction - I'll have to go back and re-read it again for about the gagilionth time.

[mostlytechnic]

Ok... I'm using an Arduino (not NXT) to control, so my code is different. But quick question:

To activate the extra address space, you use the extended mode command with the function nibble set to 0110 (toggle extra address space). Now, is that channel-specific? For example, if I send that toggle with the command set to channel 1, any receivers set to channel 2 would stay in normal space? I'm not at home to test it at the moment (and not sure when I'll get a chance...) To set a full set of 4 receivers (ie all 4 channels) to extra space you'd send the command 4x, once with each channel?

[freakwave]

Ok... I'm using an Arduino (not NXT) to control, so my code is different. But quick question:

To activate the extra address space, you use the extended mode command with the function nibble set to 0110 (toggle extra address space). Now, is that channel-specific? For example, if I send that toggle with the command set to channel 1, any receivers set to channel 2 would stay in normal space? I'm not at home to test it at the moment (and not sure when I'll get a chance...) To set a full set of 4 receivers (ie all 4 channels) to extra space you'd send the command 4x, once with each channel?

Yes, the command is channel specific. So to set 4 receivers (each on a seperate channel with the orange switch) to the extended mode you need to send the command for each channel. (lower two bits of the first nibble select the channel, function nibble as you wrote)

fW

[mostlytechnic]

Cool, that's what I was assuming. I went ahead last night on that assumption and modified my code to have the option of extra address space or not. Today hopefully I'll have time to actually get out the hardware and try it :)