Looking for a Digital Switch

[Entrastic]

Hi guys,

I am looking for some sort of digital switch to switch the control of a servo between two controllers.

I am using a CMUcam 2+ for object tracking. The head of the robot is now the camera sitting on a pan/tilt mechanism with the servos(used for pan and tilt) controlled by the camera itself.

One of the main problem I am facing rite now is that if I need to turn the head of the robot to search for objects, I will need to command the camera to cancel the tracking, then turn the head and then restart tracking again. This takes up some time and I want to avoid it. I want it the camera to continue tracking while the Robonova's controller turn the head. But I dont want the Robonova controller to always control the servos, instead only when the camera is tracking.


So now I need a switch of some sort to switch the control( basically the signal wire) of the servo between the robot and the camera. Any suggestions. Are there any logic switches available. Like a logic zero will give the control to the camera and logic 1 will give the control to the robot? If it is available, then the switch can be controlled using Robobasic.

Please help me!! Its real urgent!!

Thanx guys

[NovaOne]

Digital switch? It sounds ironic but look at an analog switches IC eg a DG411DJ http://www.intersil.com/data/fn/fn3282.pdf or similar.

[Tim]

Entrastic

The analogue switch is a good option, especially if you have several servos you want to switch.

Since you've just got one servo to control, and you are in a hurry, I thought you might like a quick bodge using a readily available part. You can construct a digital 2:1 MUX from a Quad two input NAND gate, and these should be fairly easy to find

E.g. the 74HC132 is £0.48 from RS. Maplin, bless them, seem to stock a fairly limited range . . .

Circuit diagram below:-


More details on the operation (if you're interested)



Cheers


[/img]

[Entrastic]

Thanx guys!!

Few questions more...

1) for the nand gate arrangement, what is the voltage range equivalent to logic 1 and 0?? Is the digital output from RN1's pin enough to change the states of the nand gates?

2) One major problem i will face even with a switch is that even if the camera is tracking while the head is turning, I cant read in the signals from the camera as Robobasic will let me read the input only after the head as finished turning ( by the way, the communication wit camera is thru serial ports). It would be a great help if anyone can suggest me a method to interrupt the head turning when the camera detects anything while the head is turning.

Is there anyway we can do tat ?

[Tim]

Entrastic

sorry for the delay - been on a stag do to sunny Liverpool (made a nice change from sunny Glasgow).

(1)
Logic voltage thresholds for 74HC CMOS are zero up to 1.3V, one above 3.7V (up to 5V). You can see some graphs of these for various families here

The MR 3024 seems to run on 5V, and so do the servos (control input should be in the range 3V - 5V) so you're fine there.

(2)
Re the head turning problem, how long does it take to interrogate the camera? Off the top of my head, a suggestion for a possible approach (neglecting firmware mods) could be as follows.

If you set the speed to 5, then it takes 3.3ms for a robonova servo to turn 1 degree according to this doc.

If you break the head turn from left to right into chunks that take just longer than it takes to talk to the camera, then you you could do something like this: command a section of the head turn, check the camera, decide whether to relinquish servo control to the camera or turn the head another section.

Assuming your head servo was the 17th servo, that the NAND gate switch was being controlled on port 3 (or whatever works for your setup), the following is an attempt to express the concept in code.

Warnings! I suspect there are bugs and misconceptions! Seeing as you can't use variables in servo movements, the code is pretty tedious! Also, I've not worked out whether the 'compiler' will bork when you use a GOTO to make an early exit from a GOSUB routine (it might upset the stack to have an unuseable entry in it?) - if so, the code below would get even more tedious because each segment would require its own label . . . ouch. I've not done much with robobasic yet and my last outing was with SystemC/C++ so I'm not tuned into the features/limitations/workarounds of robobasic yet...

'for the camera routine
DIM A AS BYTE

'============
turn_the_head:
'assert control over the head servo - this is the control signal to the switch circuit
OUT 3,0
'turn head 10 degrees
SERVO 17,10
'check the camera for movement...
GOSUB check_camera
'repeat tediously as follows ...
SERVO 17,20
GOSUB check_camera
SERVO 17,30
GOSUB check_camera
'code missing because it is tedious to type
SERVO 17,180
GOSUB check_camera
SERVO 17,190
GOSUB check_camera
'go back the other way
SERVO 17,180
GOSUB check_camera
'carry this on back to the starting position
SERVO 17,10
GOSUB check_camera
'go back to where ever you requested the head turn
RETURN
'============

'check the camera
check_camera:
'do whatever it is you do to get a response from the camera
'e.g. read value from AD input - just guessing here
'assume A is< 128 if nothing from camera
'assume A is >= 127 if camera wants control
A = AD(0)
IF A > 128
OUT 3,1
'camera has control of head now, until you assert OUT 3,0
'go back to main and do something else until next time you want to kick off the head turn
GOTO MAIN
ELSE
'nothing to see here, return to tedious head turning code
RETURN
ENDIF
'=======

You might also be able to use the serial HMI protocol and the digital outs to use the set servo speed using the HMI serial command, then just poll the camera. If the camera sees something, send an HMI servo command with the desired position. This way, you'd have to get the position info into the robot controller and I guessing you wanted to avoid that...

Hope that helps stimulate some thoughts on a solution . . . . I'm not set up to try it (no camera, and my RN has a head full of gyro, and chest full of bluetooth so no room for servo just now!)

Cheers
Tim

[i-Bot]

Though the analog or digital switch will make the logic changeover of the signal pulse to the servo, there is still the problem to synchronise the position between the C3024 and the CMUCAM.

An analog switch or bus switch is preferred since it is bidirectional and this might be used if you want to do a MOTORIN.

My suggestion would be to not switch the control at all. Use the servo positioning on the CMUCAM board alone for head turning. Although it is possible to stop the C3024 servo motion, you will then have to read the current C3024 position, recalculate the equivalent CMUCAM position, and then set the CMUCAM servo to that position. So easier if you used the CMUCAM positioning all the time.

Great to see so many inovative suggestions so far, and such a fast learning curve from Tim on the RN.

For the SERVO command, it will take a variable. The MOVE command will not.

The MOTOROFF command is broken in the Robobasic compiler for individual servos, but MOTOROFF G24 seems to work OK.

On the servo speed. the servo speed is controlled by a rate controller driven by a C3024 timer interrupt. SPEED 15 is about 1 degree per 4 ms, so SPEED 5 is 1 degree per 12 ms. This is at normal speed, HIGH SPEED is 3 times faster. Servo specification says 1 degree in 3.3ms, so SPEED 15 high speed is limited by servo, not by rate controller. Actual update of servos is every 12ms without Gyro, and 16ms with Gyro enabled.
This applies to a single servo moving, or to the servo with the furthest angle to move in a PTP move. Other servos move at a speed in proportion to the angle they must move compared to the servo with the greatest angle to move.

Robobasic byte code instructions are interpreted at about one every ms by the C3024

[Tim]

Hi I-bot

thanks for clearing up a bunch of my misunderstandings - very enlightening post. Good to see that at least the single parameter command can take a variable. I wonder if interpretation speed, or simply a will to avoid feature creep, was the issue with variables in the move command? Still on a very steep part of the learning curve!

Cheers
Tim

[Entrastic]

Thanx a lot guys..That was a lot of information.

Tim's initial idea of moving the servo bit by bit and checking the response from camera is not much different from the camera moving hte servo bit by bit and checking response. Since I am using the latter approach, I think I will follow i- Bot's advice and not switch control.

The field of view of the camera is decent and therefore need to turn the servos only 2-3 positions times to span a 180 degree angle. The camera is working decent this way. There is sure a time delay between reactivating tracking and analysing result and then moving servos, but it is not that bad.

I have another question tho. My camera while trackin sends a data packet of size 4 bytes. It is in this format :-

255(indicating the start of the packet)
84(indicating the packet type)
pan value( I byte)
tilt value ( 1 byte)

the cam keeps sending the packets one after the other. However, it takes quite a lot of time for the robonova to detect any data. It will wait and wait as if the buffer is empty when actually the packets are flowing in. Is there any reason behind this long pause. Am I doing something wrong.

My code is as follows

Y1: PRINT " checking "
PRINT 13

ERX 9600, type_first, Y1

IF type_first<>TEMP THEN GOTO Y1
' ENDIF

' the rest of the code to obtain the entire packet

where TEMP=84( the start of the packet)

When i run this, my screen prints " checking " for atleast few seconds before it moves further.

What am I doing wrong?

[i-Bot]

I suspect the problem might be that the C3024 does not like packets of data. The ATMega USART has 2 buffer registers, plus the receive data register, so a maximum of 3 bytes. The bytes are coming in from the CMUCAM at 9600 bps or 960 char per sec ( 1 per millisec. Bytes are read out by the Robobasic code without interrupt.

In my last post I said the byte codes are interpreted about 1 per ms. This is an average. The interpreter is fairly slow, but also the processor spends a lot of time in interrupt routines. The interrupt is every 4 ms and the processor spends 2 to 3 ms in the interrupt routine. So byte code processing is a short burst every 4 ms. This means you miss a lot of characters in the packet.

You may be able to use the output mask and poll modes on the CMUCAM, do some dummy reads(3) to make sure the receiver is empty before sending the poll. and drop the speed to 1200 baud.