Lynxmotion Tech Support

So hi every one, This is some code I tossed together it took me about an hour or so to figure out apparently you cant use the variable ch1 for some weird reason it must be reserved.

Basically I did this because I knew doing something like this could be done in a couple lines of code frankly I'm not sure why someone hasn't done something this simple before.

the output in the terminal/debug window looks something like this with all 4 sticks centered

1500 1500 1500 1500

the values fluctuate between 950 ish and 2100ish..

Overly complicated code makes me gag.

as for the technical details behind this pulsin command makes me wonder... The example they give in the atom pro manual is this
pulsin p0,1, timeout,100,duration

in my code I don't use "timeout,100" and the understanding i have behind this command it sits there for 65536 us to read and then store the value into a variable duration. I'm going to experiment with that 65536 us number and start using fractions of it until that number is so small that the value that it puts in variable is inaccurate.. goal is to have fast reads of all 4 inputs.



Now as for how fast it cycles through 1 loop of this code I have no idea honestly and don't have a clue as to how good this will work when trying to implement this in Xan's phoenix 1.3 code, I know putting this code bit I pasted above in Xan's code will be a while I need to really look at how the ps2 remote code works before i can start lobotomizing it all... I don't have a o scope or any form of measurement devices I can use to determine how fast this code is..

someone wanna try?

I don't know how cpu intensive my code is compared to the code needed for the bb2 to interpret ps2 analog stick position ...button key presses.. exct...

If someone could explain that to me or see if they have some facts as to how fast this is... does that make sense?

I would not mind stacking an additional bb2 with atom pro on top of the original atom pro with phoenix 1.3 code on it and simply using serial out at very high speed and feed the other bb2 and have it parse the serial data for the variables required to make the phoenix move around. "Although getting slightly ahead of myself not really sure this is required at this stage I don't know how sloppy my code is or if the pulsin function really is a cpu intensive or slow command to be using how I used it"

I know Kurte has shown me his assembly code so beyond me how fast that is compared to the small couple lines of mine .. kurte chime in here

Input would be helpfull!

--Aaron

_________________
Is the warranty voided yet? ... and why not?

you do understand that while waiting for a pulse using the pulsin command you are not able to be doing anything else, yes?

and if you don't have the pulses in the order they are updated from the receiver it will be more than 20mS before the next pulsin line starts it's wait, yes?

you have in fact just dedicated a $60 controller to providing sluggish at best data regarding the pulses coming from an r/c receiver, yes?

just checking.

Heheh, Eddie I appreciate your smart ass remark I'll let it slide since we have spoken before... but anyone else.. id have to bite my thumb in there general direction or slap them with a glove and challenge them to a duel!


But honestly These are the kinds of responses I want since I made this code so effortlessly and have it return values so easily and its so damn simple if I might add I'm shocked that no one has provided this code to begin with... I mean I understand its so basic but it would have saved me some silly and embarrassing posts asking for this exact thing I figured out on my own.. "go figure"

I was looking for a hardware solution to convert RC/Signals into some usable format with less latency then 20 ms "I'm not sure where you got this value" but 20ms really doesn't seem like a lot of time... seems like it could do it faster since the cpu of the atom pro is 30mhz... is this a problem with the pulsin command or some other issue... ... I guess I just don't know.

How long does it take to read the ps2 analog sticks?

Can I modify how long the pulsin command is being executed and reading that specific data line? the example I found on the atom pro pdf says its 65536 micro seconds what happens if i set the delay to 1/8th of that would the pulsin command still work as expected?

As for the actual off time and period of the RC pwm signal I would have to do some RTFM about that and figure out exactly how long I can sample it before the signal is repeated over and over again... Wish I had an OScope! I would find it highly un necessary to sample a pwm signal for more then 1 "low high low" period someone feel free to comment on this but again I dont understand how the pulsin command is actually gaining its values and what happens in this 20 ms period where that command is being executed.

Eddie as for sluggish data I'm not following you why you would say it would be sluggish data I mean you can only move the sticks so fast on a RC remote how many samples would you really need to grab in that time where you have the sticks at the lower position and move them to the highest position???

one thing I might bring up is if you say that it takes 20ms to read a signal with the pulsin command, as for implementing this into Xan's ps2 code and replacing it with my pulsin code if the phoenix would be visually less responsive?

In Xan's code I don't know how long it takes the atom pro to sample the analog stick position? on a side note I would guess the way the code is written it checks the analog stick position after each leg moves which would be 6 times a step "someone correct me on this if I am very incorrect"

if sampling the pulsin command 6 times each gait sequence would slow it down I could simply have it sample the pulsin command once every gait sequence problem with this is if i was at full throttle and jammed it backwards there would be a visual delay depending on which gait is selected.

Just some idea's someone feel free to comment on all this, and obviously I really do enjoy typing and getting my thoughts all on page.

--Aaron

*** Edit ***

So apparently I think I know why it takes 20ms that's how often the pwm signal repeats why this command is designed to sample for 20 ms is kinda silly if you ask me as the pulse widths on RC will only be at most between 1ms and 2ms at the most why it needs to be sampling for another 18ms for no data??? My guess is this pulsin command was never designed to be used for RC remote input but other items like the range finder and other PWM things that lynxmotion sells..

Sounds like a question Acidtech might be able to shed some light on maybe he can include a modified version of the Pulsin command maybe call it Pulsinrc ??? and trim off 18ms off the time it takes to execute that command.

Or can we simply run pulsin command and modify the period it samples for? "I will try this tomorrow"

_________________
Is the warranty voided yet? ... and why not?

heh, not so much smart ass but no less tongue in cheek than you comments about it being so simple and how come no one had ever thought if this before. there are details you are in the process of learning...

20mS is the rate the signal is sent from an r/c receiver to a servo. as you noted the pulse itself is only a maximum of 2.0mS duration from an actual r/c receiver. this is because the way data was orriginally sent from an r/c tx to the rx was to send the pulses one after another in a continuous stream and the first 2ms was dedicated to the first servo, the second 2ms was dedicated to the second servo, the third 2ms.... etc yada yada yada until you had 9 servos encoded. the 10th slot was used to re-synchronize the pule stream so the decoder knew where CH1 was. It also created a maximum of 9 channels... which at the time was an amazing number of control surfaces.

modern radios don't work exactly the same way and can encode more than 9 channels however because hobby servos were designed around this 20ms frame rate it persists. there is another consequence that resulted from the modernization and that is the sequential nature of the pulses with repect to each other, that is to say ch1 was followed by ch2 was followed by ch3 etc, is no longer a given. this becomes more apparent when the pulses can exceed 2.0mS in duration. some radios output all of their servo channel pulses at the same time.... which for decoding this is the worst case scenario since you typically are measuring only 1 channel at a time (with something like the pulsin command). this means to get all the servo inputs updated is 20mS x the number of channels... of which 6 or 7 is pretty common these days so you would see one set of updates at a worst case of every 140mS ... 7 updates a second. that is where sluggish comes from. also note that while the controller is executing the pulsin command it isn't doing anything else so your entire loop of commands such as controlling motors or reading sensors is gated by the amount of time it takes to read all the servo inputs.

reading the ps2 interface is very quick because the BAP is the master device and it simply goes out and asks for data as often as it wants. the actual communication to get the stick data can take less then 1ms.

if you think about how smoothly the motion is with the phoenix code such as xans and then inject even 8 to 14 mS pauses (the best case where you can read 4 to 6 channels sequentially) every 20mS it will most likely be like watching the movement in a strobe light.

interrupt based code like kurte has worked with allows measuring the time in the background using dedicated hardware in the BAP. this way the actual measuring process doesn't eat up foreground processing time. ideally when a new pulse has been measured an interrupt grabs the execution of the foreground, sticks the new value in a variable somewhere, probably sets a flag so the foreground knows it has new data, and then configures the hardware to measure the next pulse. now this again is only measuring one channel at a time so if all the pulses were coming in at the same time it would still take upwards of 140mS to get the data HOWEVER the BAP is allowed to run other stuff while that measurement is occuring. implementing that should be almost transparent to something like Xans phoenix code because the only time spent reading the signal is processing the interrupt when a new pulse is completed... which should be even less time than polling a ps2 controller.

Interesting, well Even at 7 updates a second really isn't that slow at least in my mind..

It would be very handy to have an oscilloscope right now and figure out which channel's are measured when to read them all in 1 pass..

Currently right now I have a 4 channel transmitter Futaba t4exa and a R168DF receiver "8 channel" yes an ebay special.

I was experimenting with the Adin command and when I measured the AC voltage between the black and white "pwm" lead off the reciever I got between .152 and .340 volts with .247 being the center stick voltage "AC" I think if I coupled this with a small transistor and used the +5 volts as the I believe Collector Emitter supply I could obtain a large voltage sweep using a pretty simple circuit for each channel and maybe the Adin command is less cpu intensive then pulsin. "that was another idea"

I do not think there would be a strobe effect happening with the phoenix... I think once it needs a variable it will use what it has in its memory granted that might not be updated quick enough it will still have a value to use and move.. in the mean time the bb2 with the rc receiver connected to it will be cycling through and storing those pulsin values into internal variables and each time it gets done reading all 4 inputs it blasts them out some pin via serial and the 1st bb2 with phoenix code can read them all in one go.

I thought about trying to modify the pulsin command and adjust the timeout value from 65536 -- 65ms down to 2600us "2.6ms" and see if that works but from what you say that might not work as it might sample the 2nd channel when the receiver still hasn't had enough time to output that pwm signal resulting in a 0 value in the vairable? "would this be accurate?"

Other then using the simple code I made or moving to a pwm->voltage differential with some sort of buffering method like ability to store that pwm signal into a cap as a voltage so you could read the signal in quick succession to read what the signal "was" not currently 'is" where using this method would provide a data value all the time I could see this being slightly having a delay in responsiveness but not a delay in the phoenix physical walking appearance ... one way to look at it would be you tell it to stop walking and within 120 ms it would finally stop


so if reading variables received over a serial line takes around the same time as reading values over the ps2 pin's I don't see a problem here...

however I find it quite unique how it seems like 30mhz processor cant handle something like this quicker or there isnt an electronic conversion solution that uses buffering methods to cache the value of the sticks to provide values each time the bb2 needs it.

Eddie You have brought up excellent insight to how it works, I still feel there is a Kiss method "keep it simple stupid" solution that will allow people like me to come up with a solution that has been overlooked or using an electronic circuit that converts the signal to dc voltage 0-5volts using a simple transistor amplifying circuit.

Keep this thread going seem to be answering lots of questions floating around in my head.

are there any ideas for a pure digital circuit i can construct out of off the shelf components?

I was really searching for Pulse Width Modulation conversion to "some format but was not sure what was availble to convert this to"

anyway ..

--Aaron


side note ** how can you measure something in the background without slowing down the forgound? was this the WKP stuff kurte had mentioned?

_________________
Is the warranty voided yet? ... and why not?

I think Eddie answered most of my initial thoughts. Most all of this has been covered in previous posts. In those posts I did suggest that you should probably start off with doing some simple Pulein commands to get you up and running. I am glad that you are up and running. I take it your servo wires finally arrived.

Yes having an OScope or a Logic Analyzer would be a great help. The simple Logic Analyzer I bought for $150 was well worth the money!

Several of us have started off with the same approach of simply doing the Pulsins to get us going. This works great, except that it can eat up a lot of process cycles as the BAP simply spins in the command doing nothing useful until the pulse arrives. This is time that the BAP can now no longer use to do the IK processing or maybe adapting to the terrain or can not do as many cycles through the code to make it have smoother operations.

To minimize the overhead you can try different orders of reading in the pulses. For example Zenta found on his receiver if he read them in the order 1, 3, 2, 4 it was faster than 1,2,3,4. You can easily find this out without the scope or analyzer. One approach for this is to use of the hardware timers on the BAP to measer time. I have posted code for this both under a general sticky topic in the Basic Atom forum and also in Xans code thread. There is an implemention of this in his current versions of the code.

So you can use this timer code, to keep a half microsecond timer running. You can take the time just before you do the first pulsin and then again after the last one. You can then calculate the difference. Then simply try different combinations of the pulsins until you find the one that works best for you. I would suggest that you average it over several iterations as there will be some differences as depending on where in the RC cycle you started the pulsin.

You can also do some additional expermentation of how to use the processor. For example if your receiver always generates the pulses in the order 1, 2, 3, 4, and to make it work well you find that the order Zenta used works best for you (1, 3, 2, 4), you know that after you do the first Pulsein, you have a certain amount of time before the 3 pulse will start. So you could insert some processing code inbetween your pulsin commnands to use a certain percentage of that time. Obvously you want to leave enough time to be in the pulsin 3 command in time. Likewise between 3 and 2 and again 2 and 4. You will most likely lots more time betwwen 3 and 2... I hope this makes sense.

I have tried two different software approaches to speed this in. They both have pluses and minuses. One was to write an assembly function MPulsein which can read in all of them in one Servo pulse cycle. It is a reasonably self contained function, that you simply say which IO pins you wish to read in the pulsins and give it an array for it to fill in the values. It will not return until all of the values have been received or it times out...
This appears to work well, but it still sits in spin loops waiting for IO states to change.

The other approach as Eddie mentioned was that I used interrupt processing to handle the inputs. Yes I used the WKP lines for this. You first set it up to intterupt on leading edge, grab a timer count, then set to intterupts on trailing edge get the timer count, subtract and save away the differences. This worked OK. I was processing 6 channels of data this way. The timer value may not be as accurate here as you had to wait for interrupt processing code to happen to get the timer tick values, which may be off slightly depending on chich instruction was happening when the interrupt occurred... Although I found it close enough. If I were only interested in 4 signals, I might be tempted to use the input capture capabilities of WTIMER as it is setup to do this for 4 channels (This corresponds to IO pins 9-12 on the BAP). The plus of using interrupts is that the code is not spinning waiting for something. When the signal comes, you simply grab the values maybe do a bit of calculations and then return back to your main code. Yes this does steal cycles from your main process. The downside to this is there is someoverhead in interrupts (interrupt start, register save and restore, interrupt return). This can also cause your timing loops problems. For example my MPulsin command counts exactly how many instructions happened between IO pin transisitions to know the timings, which is very accurate. Now suppose that while counting an interrupt happens that eats 100 cycles, well my calculated vaues is now off by that. This is why there have been several threads on why high speed serouts have problems when you have interrupts being processed.

The reason it takes the 20ms is that you have to wait until the actual pin you are sampling goes from a low state to a high state, at this point the signal will stay high for between 1ms and 2ms. This actual cycle can take up to 20ms. The actual pulsin knows nothing about the servo stuff nor 20ms. By default it will timeout after 65535us. You can increase the timeout by multiples of 65535. The reason for this number is the code probably simply iterrates waiting for the transisition states and adds the number of cycles that iterration took to a 16 bit register and detected when that variable overflows...

The Pulsin takes this amount of time as it has to. Here is an image showing most of one cycle of my 7 channels of the DIY. I wish I took an image showing multiple cycles but don't feel like hooking it up for this:

In this picture suppose you are trying to do the pulsin of channel 4 and you started the command at the +1ms after the 20ms. The code would have to spin until it found the signal low at about the +1.5ms. Now it would have to wait until it went high again. Unfortiontatly this is not shown in this captured image but it would be at about the 40ms mark, so the code would spin for about another 18ms before it got to this transisition. Then it would wait until the signal went back low and then it would know how long the pulse was, or in worst case over 20ms.

I hope you find some of this usefull.

Kurt

Yeah I am up and running getting these numbers I'm quite surprised how easy it was to get some numbers on the screen and have them change via RC... Neat o..

Yes the servo wires finally arrived not really sure who called it in a previous post but they are quite thin gauge for the copper inside them. anyway moving on

I'll look into finding the sticky on reading the inputs in the order the receiver pumps them out.

One suggestion was I had sent AcidTech a PM about possibly introducing a newer version of pulsin that was specifically designed to read RC inputs, but then I was going to modify the pulsin command to set the delay to around a little bit longer then the pulse takes to send the widest signal possible to a servo. .5 to 1.5ms wide I believe it was.



Yes this makes sense.





I believe this is a bit beyond me at this point seems like too much to do something so simple "to be slightly blunt about it" comments welcome.



Yes from what I understand about that is each channel blasts out 20ms worth of data when only .5-1.5ms of that is used "why they designed it that way .... maybe signals arnt far enough apart and RF interference ?? not sure" My idea was to modify the pulsin command to have a lower timeout value perhaps 2 ish micro seconds and then read the next channel... But i believe i see a flaw in this method as it would timeout on channel 2 if the receiver was still sending the remaining 17.5ms of data on channel 1, the channel 2 would be blank for quite some time and that 2nd pulsin command reading channel 2 would be zero.

as for the overflow I do notice when i debug and im watching variables there is a time when i see no data like it has overflowed and is internally reset this happens in about 5-10 seconds then its back to spitting out numbers in the debug window ... is this overflow? of the 16bit register? would the solution to be reset this register after so many pulsin reads? or is what im seeing some other problem.

so Looking at your fancy oscope logger the only way I could see my modified pulsin command to work with shortened timeout values would be to make sure the reading of my 4 pulsin commands somehow was able to be started at the instant the receiver starts outputting whichever channel spits data out first to keep all the shortened pulsinreads synced 'I hope this makes sense"

as I said previously you wouldn't want to read a channel halfway into its output or you would be getting an incorrect value..


So all and all it seem's like I have a couple options here
1) use my code on a 2nd botboard and deal with it for faster reads using much simpler code and not have to worry about which order the servo signals are sent at

2) use kurtes code 'I don't understand this at all" use the materials I already have and get it working "I'm not sure if someone has already done this and if so id love to see the source so i can try it"

3) use some other method which I still would like to try converting the pwm values into voltage or some other form of digital circuit and use something like adin function for reading the values and doing some internal math converting these numbers as for pwm conversion I really don't have a clue as what I could convert it to..

but I was thinking about using something like converting the pwm signal to voltage and using a transistor then using the 5volt off the bb2 to get a wider voltage range... I can already see problems with this how the lower the input voltage your values start degrading "your battery starts draining in your phoenix"... so don't know about this.

4) use some magic circuit no one knows about to convert this all for you to some other type of signal


5) I would not mind using an additional bb2 to loop though my simple code and have a serial link sending the other bb2 values...I do not know how much better this idea would then using kurte's assembly and 1 bb2 would having the master bb2 read data over a serial pin vs reading data on the ps2 controller take the same amount of time?

In Xan's code I do see delays when raising the body and lowering it changing gait's exct but I do not see delays when moving the analog sticks forward.

Kurte yes I find everything you say useful do I understand it all?? well about 80% of the theory I just don't know as much as you about the proper way to do things and optimizing it, seems like with 30mhz processor speed you should be able to get away with lots of slop..

_________________
Is the warranty voided yet? ... and why not?

Who ever replys please append to my previous post but I found this interesting and my syntax seems to look a bit goofy could someone assist me with the way I wrote this code particularly the plusin command, "it looks kinda cheezy"



Apparently the pulsin command needs
Pulsin "pin","pwm type","a variable","delay 40000=20ms","variable to store value of pulsin command"


Is there an alternate proper way of doing what i wrote in my syntax?

--Aaron

_________________
Is the warranty voided yet? ... and why not?

A couple of quick things.

You are using the long form of the syntax. You can drop the timeout and the label. That is what the braces in the syntax manual are for.

Also not sure about your timeouts. In both the manual that shipped with the IDE as well as the wiki shows the timeout not as a time value but as a multiplyer of 65535us. For example is states that a value of 10 will wait about .655 seconds. It is possible they updated the command and have not updated the documents...

As for why servos and RC transmitter/receivers were designed to only to update so many times a second like maybe 50 probably because that is what worked for them. The reason why most hardware implementations do them serially one after another was it worked and was an easier implementation. They know that they need to start the cycle every 20ms and if each channel takes up lets say a max of 2ms and you have a max of 9 channels, well it fits and the code is pretty easy to write.

Now it gets far more interesting when you are trying to do maybe 18 servos for a hex as 18 *2 > 20 so you need to be outputting to more than one servo at a time to make it work right.

Note: the time it takes to process this information has nothing to do with the BAP processor or the command, it simply takes this long as that is the timing of the hardware signal coming in. It would take as long on a Cray super computer. We have already discussed many different ways of working with this. Another hardware solution would be to maybe use a propeller microcontroller and simply eat up one cog to process the servo receiver...

Good Luck
Kurt

Kurt

Hey kurte,

I sent a message to AcidTech and from my understanding he codes the basic micro front end?... I think??

anyway his example was this


This code will wait upto 20ms(40000 * .5microseconds = 20ms). The default timeout for pulsin is 65535 * .5microseconds = approx 32.8ms

That was his example... Sometimes I find there are not enough examples using code to properly grasp the different ways of using the function :\

Do you have some pulsin examples?

The example I see in the pdf is
Pulsin pin, Direction, {Timeout, Multiplier,} duration

So I was using the long version but no multiplier but i wasn't using the { and } in my code

It would be nice to figure out a way to cache this signal so that the data would be available sooner, although some of the signals would be delayed by up to 160ms "8 channels worth of 20ms".. ***Edit When I say sooner I mean after it has already cycled though attempting to read the pins once meaning that the channels could be read at an instant as for waiting for the pulsin comamnds to cycle though and store the correct stick position in the variables..... some variables will be older channel position data then others... my theory is eventually the variable will be updated depending on the order of the channels i read with the pulsin command ... not quite an accurate way of doing this, but the goal would be to have data available when it needs it so it dosent have to wait ages for a vairable update "I'll see how well my silly theory works soon enough" anyway it sounds like a band aid fix i know but its worth looking into in my learning phase of all this. "HOPE THIS MAKES SENSE TO YOU"

anywho! some code examples would be handy, I guess I'm not sure how to write that code of mine without the continue labels since its obviously not necessary it simply skips that command and continues on.

from what he had explained to me if the signal is not detected that label is generally put before the command so it can jump to it and retry if no signal is found, i simply put it after so it no signal was found it moved on and the variable was set at zero ... I already see a problem with this thinking but lets move past this a second.

_________________
Is the warranty voided yet? ... and why not?

CH0, CH1, CH2 all are reserved. Page 191 of the manual starts the reserved word list.

_________________
Jim Frye, the Robot Guy
http://www.lynxmotion.com
I've always tried to do my best...

Robotdude -- Yeah I kinda figured they were reserved such as you cant make a folder called com1 in windows or lpt1 windows dosent like that..

Kurte any response to my last post? or anyone for that matter?

--Aaron

_________________
Is the warranty voided yet? ... and why not?

Hi Aaron

Not sure what to tell you here, We have gone around in circles on other options. The atompro.pdf shows several examples of using the command pulsein with exampls of how the different signals impact it.

The command has to wait until the pulse happens and unless you use some hardware support you wont capture a pulse unless you are in the command.

One option would be to not do all 4 pulseins per main loop pass. You could choose to only read one per loop and assume you loop often enough to keep them in sync.

That is all for now

Yeah I hear ya kurte..

I wasn't sure if this was covered if not shoot me a link to where it is so we don't go over things a couple times.. "forgive me im trying to learn all this crap at once"

Why was your assembly code much more advanced then simply reading the pulsin commands? I know assembly in its entirety is much better, did it take less computing power or what was the issue with this? or was it the fact it would be able to read an input while still doing the other calculations in the background

do we know what Xan used for his rc code? I'll post a topic in his thread. I can't remember when I saw it but I know xan had a video and he did individual leg control with the sticks .... I haven't seen anymore of this..

_________________
Is the warranty voided yet? ... and why not?

No problem We are all still learning. FYI - it was Zenta with the first RC controlled phoenix and did all of the impressive Vids showing moving one leg, ballance...

The main advantage of assembly is speed, but the big difference with my function is that it can read in all N servo pulses in one pass of the servos, where doing it with simple pulsein will most likely take 2 to 3 passes.

As I said another approch would be to not try to read in all of them in each pass in the loop. This is similar to a approach that Robot Dude did in the DIY transmitter code where the timing was such that he could not update all of the LCD values per pass...

Kurt