Electronic speed control
bboy8012
Posts: 153
Question is it possible to have like a listener on the prop? I.E. I want to control my speed control with my joystick, I have the app developed in java that sends it to the propeller via the serial port, but how would I get it to change the speed as say i move the slider?·Would I have to use 2·cogs for it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!
Assuming you might want to control other things with your program, you could construct
a "packet" with command types and values for receiving prop to "consume".
Hmm, getting·close to dinner time I guess [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!
I am not clear on what you are attempting to do.· So, based on what you said and what I assume, let me offer some advice.· If I am off base, let me know and I will try and help you.
You have a Java program that works on a PC and is sending serial data to the Propeller, right?· Have you proven out that interface?· Have you confirmed that a value sent from the PC is correctly received by the Prop?· For the packet, you could simple send an byte (8-bit) value for the speed or you could devise a packet of data with a header, payload and checking mechanism (CRC, etc).· The serial receive routine would be modified to only read packets with a certain header and then only move the payload to the buffer if the checking mechanism is matches, which ensures the packet arrived unharmed during transmission.
Next, in the Prop you will have at least two cogs going, maybe more depending on your application.· One cog is a serial receiving cog.· This cog could run the Parallax serial object.· This cog has a buffer for the values it receives.· Another cog would have your speed control program running.· Every time the speed control program loops, at the top of the loop, it should check the buffer of the serial COG to see if there is a new value.· If there is a new value, then use the new value for the speed control.· If there· isn't a new value, continue using the old value.
Is your joystick USB or some other special device that it needs to be attached to a PC?· If it is of the older style, then perhaps you could attach it directly to the Propeller.· Just a thought, but maybe not practical for your application.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!
this is what I have so far which is nothing, as you can see
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!
Post Edited (bboy8012) : 3/7/2008 3:45:02 AM GMT
What propeller tools do you have? DO you have a demo board or a proto board or a SPIN Stamp or similar?
It sounds like you know programming, so learning spin/asm shouldn't be too difficult. The idea of eight cogs may throw a loop in your thinking every now and again, but rest assured that the forum is here!
So, what I would do next is to experiment with the Parallax FullDuplex serial object. See the demo program. Use your Jave program, hyper terminal, or whatever to experiment sending characters to the Propeller and back to the computer. If you have the demo board, then you can setup a VGA or TV to display the characters that are received by the Propeller.
Once you have the serial routine getting parameters, then you are almost there, well as far as receiving data that is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
Post Edited (Timothy D. Swieter) : 3/7/2008 4:13:26 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!
When posting code it best to use the file|archive feature of the Propeller Tool. When using the archive function it will create a zip file that stores all the files/objects used. Also a readme text file is created displaying the heirarchy of the objects in relation to each other. This helps to ensure you post all of your code so others can help. For instance, I don't have a "FullDuplexSerialPlus" object.
In only looking at your "ThrottleControl.spin" I would say it is either the Serial.getDec or it is the other objects that are causing your trouble. Here is what I do.
-Use the serial code you have now
-add to it so that it echos back (to the PC) the speed you typed in the terminal
-If it echos back correctly, then look at the other objects, if it doesn't echo correctly then look at your serial code
Please post more information about ".gedDec". I am suspecious of this function. If you are using something like Hyperterminal and you type a speed "2" the getDec may work. (again I haven't seen the code). If you type a speed "100" it may not work because 2 was sent as one byte from the computer and 100 may have been sent as three bytes - a "1", a "0" and a "0". If you wrote a terminal program in Java, then perhaps the speed is sent as one byte. Again, this assumes that .getDec is only grabbing one byte.
I hope this helps. It is kind of vague. Post an archive zip and I will look at it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!
I recommend in ThrottleControl, have your prompt for input. (I see how FullDuplexSerialPlus works, nice object to retrieve a string). After you get the input, immediately respond with "your input was xxxx". Then put the value into your throttle routine as you are doing. Write a quick method in the Throttle routine to read what oldPulse is. You will have to promote oldPulse from a routine based variable to a object based variable. (place in the var section of the Throttle code). Doing hte above will help to verify that the data is getting from the PC, into the Prop and then into the correct COG. After you confirm the above, the next step would be to add in the trottle/ESC code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
www.brilldea.com·- check out the uOLED-IOC, an I/O expansion for the uOLED-96-PROP
www.tdswieter.com
One little spark of imagination is all it takes for an idea to explode
Meeting problems with getdec (I dont know exactly why!)·I used fullD.getstr(@mystring), ·it is not nice but it works
Command strings are like this: ·KjxAR (K to identify the robot, J for joystick, X unused, A and R letters for the C and D joystick axis).
The values for left and right servos are captured in a loop with
··· arg2:=mystring[noparse][[/noparse]2] ' pour pulseleft· joystick AXIS D
··· arg3:=mystring[noparse][[/noparse]3]· 'pour pulseright joystick AXIS C
··· Nfois:=arg1
··· Lduree:=1274+(arg2*3)
··· Rduree:=1274+(arg3*3)
Another loop in a cognew(run, @stack2) use the Lduree and Rduree values to send pulses to the servos.
If it may help , here is my program
Cats92
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!