I did an adapter board to interface an xbee digi module which operates with 3.3TTL logic to a polulu 3pi robot which operates with a 5V TTL logic.
I need it because I have to compute some information theoretic measures in real time from the robot while performing the task for my Phd research aim.
The xbee adapter contains a small LDO regulator which step down the voltage from the Vcc of the pololu to the Vcc of the xbee. A simple resistor partition on the RX pin of the Xbee converts 5V ttl from PD1 to 3.3V ttl. There is no partitor between the xbee TX and the RX PD0 port of the pololu.
So in summary the dummy schematic is:
Pololu —————- Xbee
Vcc —– LDO ——– Vcc
PD1 —– resistor —–RX
In this demo I’m using bidirectional communication as proofed in the pololu serial demo code.
I’ve just got a brilliant idea. Modify the S006 Alloy Shark produced by Syma, an indoor RC helicopter which operates in the 27MHz NA range with 3 channels with an ezChronos 430.
The ezChronos 430 provides a 3 axis accelerometer, temperature and pressure sensor. The pressure sensor can be used as an altitude estimator, so what I’m thinking is simply to get the altitude reading and see how high this toy can fly.
Ideally one could you use the sensor reading to control the asset and to limit the height but using an FM PPM radio controller is not the best solution to be interfaced with a controller, so at the moment I just want to stick to a simple “read-only” configuration.
I have some other toys which operates in IR and in that case I will be able to do something from a controller.
This is the video of the helicopter:
To be fair is not the best helicopter in that price range, but it was a gift so I couldn’t really change it.
Anyway, I have noticed that there’s some useful space in the front chassis so I have decided to open it and try to fit an ez430 chronos inside.
This is the helicopter opened:
And then the chronos inside:
Now the main problem to get the altitude reading is that I cannot press the button of the ezChronos to start the wireless communication so I have to tweak the open chronos firmware to give me a continuous communication with an interrupt.
The idea is that the ezChronos will wake up every 1 second (with an interrupt) to check if the base station is available to receive data and then eventually start the telemetry function.
In the next article I will talk about the software module.
this is my last ultimate hack for the mindflex. I wanted to reproduced the results of the mindflex as indicated by the manufacturer.The simplest test that can be done with an EEG device is to check if the alpha waves go up significantly when closing your eyes.
However doing some test with different subjects (i.e. my guinea pig students/friends) and with or without electrogel I couldn’t find any prove that the neurosky chip is working properly.
I will be happy if somebody can reproduce a high alpha activity with closed eyes.
I could only see some random peaks in the alpha activity during closed eyes which were not stable.
So here the instructions for 2 configurations that can be used to log the data and save it to a CSV file.
So you take out of the shell 3 wires: black is the GND, blue is the Vcc=3.3V and white is the TTL signal at 9600 bauds.
I made 2 possible configurations one which uses a BUB board (based on the FT232 chip) to read the EEG raw data
stream directly to the computer and one which uses a xbee transmitter and an xbee receiver.
As I said before I totally desoldered the original radio modem that was on the main board inside, as in Figure.
What can I do with that? I have no idea! :-p
The first configuration is the most dangerous one since you are connected to your
computer via the usb without any opto-isolation so DO IT AT YOUR OWN RISK.
Make sure you put the jumper of the BUB board over the 3.3 V level,
the black wires goes to GND, the white wire goes to the RX pin and the blue wire is not required because we don’t need the 3.3 Vdd, so I just put it on an unused pin of the bub board.
The second configuration is more interesting because uses a pair of xbee modules to send the eeg data over the air, thus avoiding electrocuting yourself for some hardware faults.
The xbee connected to the MindFlex should be configured in this mode:
ZNET 2.5 ROUTER/END DEVICE AT
PAN ID 1AAA as the one in the Xbee host receiver
DH-DL as the SH SL of the Xbee host receiver
PL power level: 2 MEDIUM
SERIAL INTERFACING is the most important:
Set the BAUD Rate to 9600 with NP no parity
The xbee connected to the computer (host receiver):
ZNET 2.5 COORDINATOR AT
PAN ID 1AAA as Xbee sender
SERIAL INTERFACING is the most important:
Set the BAUD Rate to 9600 with NP no parity
This is the final integration, I used an Xbee breakout board and drilled a raw of holes to fit the pins.
Now the next thing is to parse the data coming from the serial port,
The code is written for the Processing environment and I have compiled
and put the source codes in the zip file provided.
This is my stable alpha activity during opened eyes which doesn’t differ much from the closed eyes condition!
The export saves in CSV format.
For the open eye condition: UP arrow start recording, DOWN arrow stop recording
For the closed eye condition: LEFT arrow start recording, RIGHT arrow stop recording
File are saved in the same folder, you can then import them in Matlab and plot.
The opened and closed eye condition does not discriminate in the alpha band.
Elettrogel does not improve the condition.
Even flipping the MindFlex so that the electrode is touching your backhead (close to the visual cortex) does not improve the discrimination.
The problem of all consumer EEGs is the connection between scalp and amplifier. When measuring EEG in the lab there is quite a lot of effort going into making proper contact with each and every electrode each and every time by measuring impedance and carefully preparing each electrode.
The problem with EEG in general is the inherently bad SNR. If you have no properly connected (Ag/AgCl) electrodes, you’re not gonna get reliable signals, period. The voltage is so small, the DC polarization alone you get with mindflex electrodes might be several hundred times the signal and probably contains huge amounts of AC noise, too.
However I expected something more from the Neurosky guys because their marketing in terms of benchmarking is quite aggressive …. There’s is something going on in the toy but is not really really stable!
If you don’t trust me you can do the following, download these 2 CSV files containing the condition with opened eyes and closed eyes and try to determine which number is the open and which one is the closed.
I decided to interface an XBee Series 2.5 from DigiMark without using an external Arduino or MegaDuino which is bulky and technically unsafe for the missing opto-isolation interface between the electrodes and the main voltage.
Anyway! The interface is very simple: 3 wires.
The T pin on the daughter (neurosky chip) board is the TX (blue wire), the V pin (red wire) is the supply voltage 3.3V regulated from the batteries and the ground pin is either at the negative pole of the edge (black wire under the main board) or also at the right of the V pin.
I would suggest to solder on the - pole under the board because you can easily short circuit the V pin withe the GND pin which are only few millimeters apart.
I checked out with the oscilloscope and the V is a low ripple DC at 3.3 V which can be used to power up the XBee.
So the V pin goes into the pin #1 of the zigbee, the T pin goes to the pin #3 of the xbee (DIN) and the ground pin goes to the pin 10 of the zigbee.
The Xbee must be configured in AT mode to rely the incoming serial transmission at 9600 bps into the node coordinator.
Another xbee connected to the pc via the usb explorer simply receives the data in AT mode.
The processing library developed by Eric Mika can be used to decode and show the data.
This video (very poor quality sorry guys) shows a dump of the first successful attempt, I didn’t have time to make a decent video yet.
The next great thing to do is to desolder the RF module on the board and see if the the neurosky chip will still send the raw data even if the RF module does not answer.
I also tried out a LIPO battery of 3.7 V @1100 mAh and it works great, it can also fit inside the battery pack.
I will post the pictures relative to the battery when I have time, I’m slaking off my official work!
I’m doing a feasibility study for tracking objects and persons in terms of range and motion.
The first prototype is based on 2 nodes:
an arduino with an xbee shield and a speaker.
a xbee 2.5 series 2mW antenna + ADXL335 + power supply + signal filters.
The 2 prototypes uses the zigbee API mode to communicate and check if they are moving away from each other. They measure the signal power as well as the motion to estimate the direction.
An xbee explorer works as an internet gateway if connected via usb to an host pc.
The relationship between RSSI and feet in open space can be interpolated using statistic sampling.
Somebody did it already and this is the curve.
RSSI vs Feet
The second prototype is based on 2 nordic keyfobs and 1 usb interface.
The only problem I encountered with the nRF24L01 chips is that the value for the RSSI is binary: 1 bit to detect either an RSSI under -64dBm or an RSSI over -64dBm.
They are provided with 3 tilt sensors for inclination (max 15 degree) to consume less power (4uA average current) and can be connected to the internet as well with the serial usb interface.
This is an experimental setup to control a prosthetic leg built with the Lego NXT.
The leg is planar and has 2 degree of freedom, one for the knee and one for the ankle.
There are 3 sensors: a gyroscope at the thigh, an ultrasonic sensor at the hip level and contact sensor at the foot tip.
The gyroscope is used to measure the angular speed of the extension/flexion of the thigh and can be integrated to estimate the absolute angle of the thigh with the ground. The contact measures if the foot has touched something. The ultrasonic sensor measures the distance of the hip to the ground when the leg is extended.
The lego NXT has 2 powerful servomotor which can control the knee and ankle orientation.
The human operator position of the knee and ankle is tracked by using 2 accelerometers placed at the proper positions.
The 3-axis accelerometers are wireless connected to the PC (I’m using the ZStar kit) which runs a C# environment. The host program receive the filtered readings from the sensors and then sends the angular positions to the program running on the NXT via bluetooth.
I used the NXT Osek real time environment on the NXT brick for trajectory planning.
The control system receives angular position and speed from the human operator and using a PID control setup the angular position and speed on the artificial leg.
This video shows some preliminary test with PID control on position but not speed.
I’m working also on a prototype with sEMG (surface EMG) using a USB-DUX with a bio-amplifier.
Here is the first test I did for the left leg hyperextension in sitting position.
Duration of 20 seconds and 3 repetition (the last one is discarded) with a wireless Freescale MMA7361L at 30 Hertz sampling rate with 1.5 g scale.
For slow movements where the peak of extension is reached after about 1 second from relax to extension we have an angle of 47 degree which I manage to keep for 2 seconds.
Previous studies such as (3D joint rotation measurement using MEMs inertial sensors: Application to the knee joint) reports an angle a ROM of 51 degrees but they used a 9DOF unit and some advanced compensation/calibration techniques.
For a digital accelerometer I would say is not too bad!
Here are some pictures of the positioning of the sensors. Only the knee one was used in the test.
A braille reader can read up to 200 words per minute (Foulke 1991).
In this tutorial I’m going to show how I implemented the electronic part for an innovative braille interface that can be connected to a computer via USB. The idea has been patented by my friend Nial Slater.
The poster describes the concept behind the innovation:
The device is composed by:
6 buttons on the top side:
3 buttons for the left hand and 3 buttons for the right hand
a rather special sheet that emboss on the fly braille characters
a set of 6 microactuators (and NO they are NOT simpe solenoids!) that emboss on the special sheet
Now the first prototype was built to emulate the braille encoder:
how to encode the 6 buttons combination into the corresponding micro actuators output.
Because the micro actuator has the same current draw of 40mA LEDS we decide to use 6 LEDS and dispose them to form a braille matrix.
We wired the arduino 2009 in the following way:
PINS 8~13 are connected to the 6 LEDS with pull down resistors
PINS 2~7 are connected to the 6 buttons with pull-up resistors
The reader will ask why the pull up configuration!
Because a braille typer works in a reverse way: the pins emboss the layer only when 1 or more than 1 buttons are released! This imply that:
in average the buttons will be pressed: therefore we do not want to drain any current!
This explanation doesn’t make sense unless you do not debug it in your head.
Assume the buttons are number from left to right as an array, when all are pressed you have:
A= 000 000 (because of the pull up)
And when they are not pressed:
If the typer lift the index of the left hand, the status will become:
There was a transition from high to low of the MSB bit and only this pin should be activated to emboss the letter A!
The arduino code makes use of port registers and clever arithmetic operations on the PORTD and PORTB to detect the trigger of HIGH -> LOW BUT no the trigger LOW -> HIGH and then do the output of the differential status onto the LEDS matrix.
I also included a more intuitive coiding which simply copy the button configuration to the ouput LED, and also a cool features where the user input the ASCII letter on the keyboard and the arduino will output the braille encoding on the matrix. I left the reader the task to finish the braille encoding.