pulsin then servo

[alband]

pulsin then servo + gyro

I've built an RC tank. It has two servos in the turret and the receiver in the hull (bottom). One servo is for gun elevation and one is to turn a laser of and on. Because the turret spins round indefinitely I am using a four contact (VCC, GND, servo1 and servo2) 3.5mm headphone jack, male in the hull, female in the turret. The problem with that was the female section was two big. To solve this I'm now using a 3 contact plug from an iPod (that was already bust) and adding a fourth GND contact but gluing a scalectrics pick-up to the bottom of the jack. This works but isn't very reliable - at certain points in the turret rotation, the GND looses contact and the turret switches off.
What I want to do is have two 08M's; one in the turret and one in the hull.
The one in the hull reads the two pulses coming from the receiver using pulsin and then send them through a normal, 3 contact headphone jack to the 2nd 08M.
This therefore only needs three contacts; VCC, GND and serial.
The 2nd 08M receives the the data and turns the gun elevation data into a servo command and the laser state into a simple on/off.
The problem is: pulsin gives a number between 0-65535 and the servo command requires a position between 0-255.
Can I simply divide the pulsin number by 257 and us that as the servo variable or is it more complicated than that?
Also, once that is working, I want the gun to go up, like on real tanks, so that it doesn't hit the rear hull. How would I do this?

 

[papaof2]

Headphoe jacks are not that reliable for in-motion connections. Something made for rotary connection would be better. Or use something with gold contacts. My junkbox has some gold plated pins from a charger for an older Motorola handie-talkie - see if there's a two-way radio repair shop near you that has some old stuff ;-)

For the "lift at the rear" function, a couple of limot swtches, either microswitches or magnetic reed switches, could be used at the proper points on the circumference of the turret and the switch contacts (normally open, wired in parallel) would go to a pin on the 08M. Use the interrupt command so you always detect the operation of one of the switches.

John

 

[BeanieBots]

I'd agree with papof2 for the turret gun lift system. A simple cam on the turret would be all that's needed to activate the uSwitches.
As for pulsout/pulsin. If you send using "pulsout 150" then you will receive 150 using pulsin. The fact that the maximum range is 65535 is irrelevant.
You should test the pulsin value for numbers which are out of range to avoid damaging the servo.

 

[alband]

I think the point has been missed, I'll try again...

At the moment the contact is unreliable because I've had to make a contact so that I have four. The headphone jack by itself is very good I've found (try turning the jack connected to your headphones and listen for skips).
I therefore need to us the standard three contacts but I need to send information to two outputs. This would normally require a separate wire for:

VCC
GND
Data1
Data2

I plan to collect the data's with an 08M in the hull and then send it (serout/serin) to the second 08M using only one contact.
The problem is; how to capture and replicate a servo signal. Idealy I would use "servoin" but it doesn't exist. So, I need to use pulsin and then turn that data into a servo output.
e.g.
Hull:

main:
		pulsin 1,1,w0
		pulsin 3,1,w1
		serout 2,T2400,(w0,w1)
		goto main

Turret: (not including that gun rear raising thing)

		servo 1,100
		low 2
		setint %10000,%10000
		
main:		if b12 != 1 then main
		servo 1,b4
		if w1 > 50000 then
		high 2
		endif
		goto main

interrupt:	serin 4,T2400,w0,w1
		let b4 = w0 / 257
		let b12 = 1
		setint %10000,%10000
		return

 

[BeanieBots]

Well using serin/serout will have the normal "lockup" problems and I believe there will also be issues using servo and serial at the same time.
How about sending two output pulses and then receiving two input pulses?
Might be a problem keeping them in synch but worth a try.

 

[alband]

What lockup problems?

 

[hippy]

What lockup problems?

That the PICAXE cannot be outputting SERVO pulses while waiting for SERIN, but then it cannot while waiting for PULSIN either. However, with a suitable delay it should still work, self-synchronising to the master PICAXE's loop timing ...

Do
Serin serialPin,baud,b0,b1
Servo rotationPin, b0
Servo elevationPin, b1
Pause somewhatLessThan20ms
Loop

or something like that.

 

[InvaderZim]

The lockup problem, as I gather it:

If you want to write a program to use serin/serout to communicate between two picaxes, you'll start with the "slave" doing something useful. But at some point, you'll have to check for a serial command coming from the "master." To do that, you can just use a serin command. But there's a problem; the way serin works is it will stop all processing until it receives something. So your slave could be useless (locked up) for a long, long time while it waits for a command. Depending on your application, that might or might not be acceptable. On a side note, a picaxe in such a state might need to be manually reset just before a program download, since it is "stuck" waiting doing something else.

I've thought a little about the lockup problem (as I'm sure others have!). One idea I came up with is to check the state of the serin pin on the slave with an interrupt (or by polling). When the master wants to send data, it will first manually transition the output pin from the idle state to the opposite state for a minimal duration, then return it to normal. This will flag the slave to "listen up" and prepare for incoming data. The interrupt (or regular subroutine) will wait for a return to normal state and then issue a serin command. Serial data should come along in a minimal amount of time. After the input, the slave can return to business as usual.

Overall, I see this scheme as minimizing the awkwardness of serial communication without comprimising data or taking a lot of extra code. And it also only requires the one pin, just like usual.

Sorry if I've re-hashed anyone's idea, I haven't researched this at all (or even tried it out myself, so double forgiveness if I've got a bum solution!)

 

[alband]

Oh, well I've dealt with that using the interrupt. It goes through the servo routine and then only when the interrupt is triggered does it wait for the serial communication. I forgot to ad the high pulse in the Hull code to trigger the interrupt.

main:
		pulsin 1,1,w0
		pulsin 3,1,w1
		pulsout 2,1
		serout 2,T2400,(w0,w1)
		goto main

Also there would only be one servo; gun elevation. The other will just be a simple high or low depending on the second variable to control the laser.
I'm not sure what to do about the servooutput and serin problem. When the serin command is executed, the servo command stops, does it go back on as normal once serin has recieved its data?
Even though it would only take a miliseconds of time for the chip to execute the serin and therefore the servo out not being on, the servo wouldn't work if the pulse is lost:

page 154
Once the pulse is
lost the servo will lose its position.

If, however I removed power to the servo while the chip was searching for serin, the servo would stay in the same place. Would there be any way to switch off the power to the servo.

 

[BeanieBots]

If, however I removed power to the servo while the chip was searching for serin, the servo would stay in the same place. Would there be any way to switch off the power to the servo.

Removing the pulses will have exactly the same effect as removing power on a 'normal' servo. You can also get digital servos which are programable (requires programmer). They will either go to a predetermined postion or hold existing postion when pulses are missing. Another 08M can of course be used to create such a function much more cheaply.

 

[alband]

I think I'm using a digital servo. If I am do I only need to send one servo command and it will stay in that position if it doesn't receive any other commands? (ignoring the fact that "servo" keeps going in the background whilst "easy" commands are being executed.)

 

[BeanieBots]

If it's a digital servo, then it will do whatever you programmed it to do when there are no pulses. If you don't have a programmer, maybe your local hobby shop could program it for you.
So, yes, you could send a single pulsout and it would then hold position.

If you say your servo is strong enough to hold postion when power is removed, then it's not a problem anyway (with a 'normal' servo). Just stop sending the pulses. The effect is the same as no power.

Try it!

 

[alband]

Ok, say that works (I'll have a big trying session later) what about turning the pulsin variable into a servo command. servos generally only go 75-255 yes?
The pulsin can vary from 0-65535 but due to this limmitation, will it only vary from 19275-65535 and would I therefore only have to divide the number recieved from the pulsin by 257 e.g.

nain:
		pulsin 1,1,w0
		pulsin 3,1,w1
		b0 = w0 / 257
		serout 2,T2400,(b0,w1)
		goto main

 

[BeanieBots]

As I mentioned earlier,
pulsout 150 will be received by pulsin as 150.
If there's no pulse, pulsin will return 65535, so simply ignore it.

 

[alband]

Checked the servo.
This is the current gun elevation servo (don't think it's digital)
This could be used instead. (that is the most info I can find on it )

 

[alband]

The pulse will be coming from an ordinary RC receiver though, designed to go straight to the servo...

 

[BeanieBots]

Didn't need to go past the price.
That is NOT a digital servo.

 

[boriz]

Have you considered infrared? No contacts required except power. No need for the body mounted Picaxe at all. Just use a transistor to amplify the current from your radio RX servo output. Drive a ring of IR LEDs under the turret. An IR phototransistor on the turret will switch in sympathy with the ‘IR ring LEDs’ and that might be able to drive a servo directly or be decoded by the Picaxe.

Whatever method you choose…

A single servo channel is easy to decode using PULSIN. It consists of a rising edge, followed by a high time of between 1 and 2 mS, then a falling edge, then about 20mS later it happens again. The duration of the high is the information you want. (See here)

PULSIN measures units of 10 microseconds (uS), and there are 100 of these 10uS units in 1 millisecond. So if your PULSIN reads 120, that is 120*10uS = 1.2mS.

Think of 1mS being ‘servo all the way left’ and 2mS being ‘servo all the way right’ and 1.5mS being ‘servo centred’. This is a generalisation and the precise figures will vary a little from servo to servo.

According to the SERVO command Docs, 75 is ‘servo left’, 225 is ‘servo right’ and 150 is centre. (again this might need tuning a little for your particular servo)

So you need to convert a PULSIN value of between 100 and 200, to a SERVO value of between 75 and 225. Personally I’d probably work around the centre point, IE a PULSIN value of 150 is the same as the SERVO value of 150, both are the centre point. ALWAYS limit the value given to the SERVO command to no less than 75 and no more than 225, or servo damage could result.

I’m sure you can figure out the rest.

One important thing to note is that the signal is repeated every 20mS, so your Picaxe software HAS to complete a loop WITHIN 20mS, preferably <18mS, and be ready with the next PULSIN command. Otherwise you can get unpredictable results. Don’t be tempted to use a higher clock speed. The SERVO command won’t work.

 

[alband]

That's the stuff.
Obviously, I'll try to keep the loop as short as possible but how can I tell how long the loop takes?

 

[alband]

Oo, also I need to measure two channels using pulsin and need to have a pulsin ready and waiting for each one like you said. Will both pulses come from the Rx at the same time or would they be staggered?
Also, does it matter if I collect the pulse from channel one and miss the channel two pulse, and then collect the channel two pulse and miss the channel one pulse - repeat. Because the code at the other end gives a servo out pulse of th most recent number and doesn't keep looking for a pulse this should be OK?

 

[BeanieBots]

The more "traditional" receivers send the pulses out in sequence but all are still within the 20mS frame.
The newer 2.4Ghz receivers tend to send all pulses at the same time.

You need to pick your channels carefully and test them in the correct order if you want to read them within the required frame.

Experiment on YOUR equipment.

 

[alband]

I'm posting this mostly as a quick way to transfer it from PC - PC so I can try it, but have a gander.

main:
		pulsin 1,1,w0
		pulsin 3,1,w1
		let w0 = 150 - w0 'this section converts pulse data into servo number
		let w0 = w0 * 3
		let w0 = 150 - w0
		let w1 = 150 - w1
		let w1 = w1 * 3
		let w1 = 150 - w1
		if w0 = w2 then 'this check wether the numbers have changed
		if w1 = w3 then main
		endif
serial:	pulsout 2,1 'interrupts other 08M
		serout 2,T2400,(w0,w1)
		let w2 = w0
		let w3 = w1
		goto main

		servo 1,100
		low 2
		setint %10000,%10000
		
main:		if b12 != 1 then main
		servo 1,b4
		if w1 > 50000 then
		high 2
		endif
		goto main

interrupt:	serin 4,T2400,w0,w1
		let b4 = w0 / 257
		let b12 = 1
		setint %10000,%10000
		return

 

[Wrenow]

I you are getting the original pulse form a R/C RX you are in luck - it will be exactly the same as the servo or pulsout you need on the other end. Just be sure to reject anything outside the normal range of the servo (say 75-225) as errors to get rid of glitches.

If you are using a regular, old-fashioned R/C system on ground frequencies (75MHz, 49MHz, or 27MHz in US, different in other countrys), you are in luck. Just mount an independent RX in the turret, and use the channels you want from there - you are good to go. The TX is a broadcaster, it doesn't know or care how many RX's are out there receiving the signal and acting on it. We have used this in RC Model Warship Combat to run two ships at once from one TX, one using the left stick for throttle and rudder using the normal channels 2 and 4, the other using the right stick using channels 1 and 2.

If you are using one of the newer 2.4GHz radios, however, this will not work, With the 2.4GHz systems, both the "TX" and "RX" are actually transceivers, and it is a bound, closed, system with both parts talking to each other. No second RX allowed.

Cheers,

Wreno

 

[alband]

I can't just have two Rx's because it would be too big and too expensive. The whole tank has 5 channels:
Left Track
{ merged }
Right Track
Turret rotation
Gun elevation
Laser on/off

I would therefore need one 5 channel Rx in the bottom and another 5 channel Rx in the top. This is just impractical.

Are you sure however that the pulsin will be the same as servo out?
e.g.

main:
pulsin 1,w0
servo 2,w0

 

[alband]

Well, I've had limmited success.
I've got one of the servos going controlled by a pot, but that's about it.
I can seem to get the pulsin working at all.
This is the code I'm using to test it:

main:		pulsin 2,1,w0
		debug w0
		goto main

 

[alband]

I've solved the pulsin problem.
It needed a pull down resistor.
The problem now is:
I've got this on one chip:

		servo 1,150
main:		pulsin 2,1,w0
		if w0 = w1 then main
		let w1 = w0
		servopos 1,w0
		goto main

and it works except the servo (and thus the gun) jitters emencelly. It jitters around the desired position though. I debuged it and it is because the pulsin command retrieves a value that swings around by about 20. Any ideas what's wrong/solution?

 

[BeanieBots]

Are you sure however that the pulsin will be the same as servo out?
[/CODE]

This has been mentioned in almost every reply, and it is true.
It is has also been mentioned several times to check that the pulses are within limits.

Not sure what might be causing your 'jitter'. Are you checking to see that the pulses are within limits? Ignore pulses which are not.
Have you tried without the drive motors etc. ie eliminate noise first.

 

[alband]

I must have missunderstood previous posts.
No worrys on the limits; I have debuged them and can control them with the Tx. Thanks for your concern though.

Typically the jitter went away as soon as I posted it rolleyes and I'm now trying to get it to work through two chips with both channels - I might be very quite for a while...

 

[InvaderZim]

Just to clarify: were you trying serin on the turret, and having trouble with the servo pulses pausing? Since servo pulses are 20ms apart, I'd have thought that if you kept your serial communication down to about 2ms, the servo would never notice. That's about 1 byte at 4800 baud, assuming minimal lost time while the two pics coordinate the start of the transfer.

Question for the forum: Are analog servos only sensitive to the pulse duration, or are they sensitive to both duration and frequency?

 

[BeanieBots]

I must have missunderstood previous posts.
No worrys on the limits; I have debuged them and can control them with the Tx. Thanks for your concern though.

You've missunderstood the point about the limits too.
You need to check the limits AFTER the pulsin command.
If your pulsin times out, it will contain 655535. You don't want to send that to your servo. If your input is not connected to the Rx or the Rx is on but the Tx is off or out of range, pulsin could give almost any value. Simply sending the pulsin value without checks is very likely to kill your servo.

As for using a second receiver, that's a brilliant idea. You can get ultra small Rx units at quite reasonable prices.

 

[BeanieBots]

Question for the forum: Are analog servos only sensitive to the pulse duration, or are they sensitive to both duration and frequency?

Depends on the servo.
MOST are not very fussy about frame rate. I have found that it is the "strength" of the servo which depends on frame rate. The Hitec type will actually be much stronger when driven at a frame rate of 10mS rather than 20mS. This something I have taken advantage of in my Hexapod design which can be found in the Robots section. Note, there isn't a single servo command anywhere in the entire code.

I'd suggest alband to use pulsout rather than servo. Not only will it avoid issues with using serin, but the frame will be automatically set by using pulsin on the already framed Rx signal.

 

[alband]

Right. I know I said I was going to be quiet, but my Tx has the most pathetic battery pack IN THE WORLD and needs to charge. Once it's back I'm going to start debugging the Hull; I had the two chips wire up but nothing happened so I'm checking stuff.

I just cant use a second Rx, as easy as it sound I would be too big at any sensible price (its a 1/35 Tamiya M1A2 Abrams and it's full). Besides, if it's possible with what I've got, I'd like to do it (know the feeling? )

Not only will it avoid issues with using serin, but the frame will be automatically set by using pulsin on the already framed Rx signal.

Sorry, I'm a bit thick today (and any other for that matter), not sure what this means but it sounds good.

As for the limits, this servo has proved its meat, and after doing lots of debugging, no limits have been breached, it would also take longer to run the code with limits. I'm turning it on in this order; Tx, Rx, Chips, servo, so there shouldn't be any timeouts. Also I'm never going to send a value of more than 255 - see the attached latest codes as to how.

I now will be quite for a while as I of to loose at squash .

Thanks for all the patients.

 

[BeanieBots]

Your choice if you don't want to check for limits.
You can get spare servo gears very cheap. Get a few packs, you WILL need them.

Pulsin will not exit until the pulse has been received. As the pulses are sent every 20mS, your code cannot pass the pulsin command more than once every 20mS (except when there is dodgey pulse, have those spare gears ready).
You will have about 19mS to do whatever processing is required before the next pulse. Range checks should not chew up more than 2mS of that. Also, if you use pulsin/pulsout rather than servo, you can over-clock but I doubt you'll need to. My hexapod checks the "eyes" calculates all the new positions for the legs & direction and runs at DOUBLE frame rate all at 4Mhz.

 

[alband]

Well, Its going OK.
I'm having trouble getting the chips to communicate.
Attached is the code.
I've debugged the hull at the point where the serout occurs and the values are great; very even, no jittering and b2 is 0 or 1 when it needs to be (laser).
You can see I've got a pulsout before the serial communication to interrupt the turret chip.
Ha; was in the middle of writing the checks I'd done and double checked one as I wrote this - the wire was in the wrong place.

Anyway. In the Hull b2 switches between 0 & 1 nicely but when received I get either 11 or 3.? As for b0; is messes around between 0 and 225.

 

[Wrenow]

For what it is worth, I would also recommend going to pulsout instead of servo in this application. You are trying to update the servo command every 20ms, with every pulse. With pulsout, all the frame timing is handled by the RX, so you are good to go.

Do be aware that this is going to be an electrically noisy environment, and appropriate filtering and conditioning is in order.

As for the RX being bigger and expensive - perhaps not. As BB mentioned, "You can get ultra small Rx units at quite reasonable prices." (BTW, thanks for the complement on the idea, BB - it is something that is pretty common knowledge in RC Model Warship Combat as a spare tool in the shed for when you need it, though not often needed).

What frequency band are you running? There are several quite tiny 75MHz RXs (smaller than some bare Picaxe chips) available out there (and some on European frequencies) that are not prohibitively expensive, as well as some dirt cheap ones on 27MHz that are pretty darned small. One example of the 72/7fMHz is the Sombra SL-8, which is 37mm x 20mm x 12mm (Vertical pin version), and also comes in a horizontal pin version if that fits better. It is a tad expensive, approaching CA$65, but does not require a crystal, so that saves you some cash as well.

You can get some 75MHz 4 -6 channel ones even cheaper (I have bought some for under USD $30) that are even smaller than the Sombra (iff you don't count the crystal).

Tha antweight robotics guys and indoor flyer crowd have really helped us here.

If I knew more about your setup, I might could point you better. What I would ned are: Operating frequency band and whether the RX is a separate RX or is integrated into the system (i.e., part of a board that has the speed controllers etc. included). Again, if you are using a 2.4GHz system, this methodology will not work.

Cheers,

Wreno

 

[BeanieBots]

Details of the radio would indeed help.
In the UK, we have 40Mhz for ground and 35Mhz exclusively for air.
If you don't mind a slight reduction in range, it is possible to put a 40Mhz crystal in a 35Mhz receiver. That opens up many possibilities. For example, a micro-heli receiver (not VERY cheap but only 10X10X20mm) will give you 2X 5A motor speed controllers and 2 servo channels. Just turn the giro gain right down but a little gain actually helps with tank-steer models. No reverse though, not much call for it in helicopters!

 

[alband]

I haven't got 10x10x20.

FYI I'm on 35Mhz and separate but I'm determined to get this to work.
I've got the variables correct at one end but as soon as the get to the other, they are regularly different. 0 turns into 11 and 1 into 3.?

Does the serial line need pulling low?

 

[BeanieBots]

Fair enough.
The serial line should not need pulling in any direction.
Are you still getting good values from pulsin?
Is this direct wired or via the turret 'slip' connection?
Try without the 'slip' first.

 

[alband]

Thanks for giving up on the 2nd Rx, in theory it sounds great and I hope others may find it just the kind of idea they needed. I'd considered it before when designing the whole thing but in reality, it just wouldn't work at any reasonable price.

Everything is in the breadboard except the pulsin wires, the GND's are connected and the servo is connected to its own 6V supply and to the chips when necessary via a 330R. The serial wire isn't attached to the jack and is just a wire at the moment.
The values before the serial communication are fine but after being sent, each value seems to adopt an alternative value.

 

[BeanieBots]

Are you still doing that odd stuff with "setint" and "servo"?
Just a simple serin and pulsout in a tight loop.
(assuming you still can't be bothered to test for limits, they're your servos!)