Xbee communication, strange behaviour
Steady
Posts: 3
Hi everyone!
Maybe somebody came across the problem which I'm currently dealing with. Or has an idea ?
First of all, to give you an overview : We've made a 32x50mm prototype pcb for a helicopter stabilisation purpose,
which involves a Propeller, ADXRS300 Gyro (z-Rate), IDG300(xy-rate), ADXL330 (xyz-accl.), MCP3208 ADC, uM FPU, USB-RS232
converter for programming and debugging and the i2c eeprom off course . Two pwm-controlled n-channel mosfet motor drivers for the coaxial
rotors. The "power supply" is also on the same pcb, which consists of 3,3V and 5V linear-regulators as well as 3,0V and 2,5V precision voltage reference
sources for the adc and accelerometer (3,0V) and z-gyro (2,5V).
The accelerometer doesn't have a specific ref input, it's just an radiometric device.. that's why I power it directly with the voltage reference source which
is capable of delivering those few hundred uAmps needed by the adxl.
The remote interface consists of a xbee pro serie 1 module, which is currently not working properly. We're transmitting at 19200baud, no parity, single stop bit.
As long as we control the whole thing using the usb/rs232 interface everything works fine... the data is received properly and we're able to control motor speed,
servo position and so on.
if we change the the interface... from wire based to xbee, everything works well for a few seconds and freezes later on, just to mention, we use different ports for
programming/wire based transmission and xbee transmission, so they are completly indepentend from each other. All we do is just changing the ports form 31/30 to 14/15.
the modules are configured corretly: 19200baud, no parity, single stop, packetization = 0 (characters are transmitted as they are received). We do not use any character
that could cause the module entering the "programming mode".
Still it does not work correctly... just a few seconds and then it freezes. I hope there is not to much wrong, as english is not my mother tongue.
Thank you.
Maybe somebody came across the problem which I'm currently dealing with. Or has an idea ?
First of all, to give you an overview : We've made a 32x50mm prototype pcb for a helicopter stabilisation purpose,
which involves a Propeller, ADXRS300 Gyro (z-Rate), IDG300(xy-rate), ADXL330 (xyz-accl.), MCP3208 ADC, uM FPU, USB-RS232
converter for programming and debugging and the i2c eeprom off course . Two pwm-controlled n-channel mosfet motor drivers for the coaxial
rotors. The "power supply" is also on the same pcb, which consists of 3,3V and 5V linear-regulators as well as 3,0V and 2,5V precision voltage reference
sources for the adc and accelerometer (3,0V) and z-gyro (2,5V).
The accelerometer doesn't have a specific ref input, it's just an radiometric device.. that's why I power it directly with the voltage reference source which
is capable of delivering those few hundred uAmps needed by the adxl.
The remote interface consists of a xbee pro serie 1 module, which is currently not working properly. We're transmitting at 19200baud, no parity, single stop bit.
As long as we control the whole thing using the usb/rs232 interface everything works fine... the data is received properly and we're able to control motor speed,
servo position and so on.
if we change the the interface... from wire based to xbee, everything works well for a few seconds and freezes later on, just to mention, we use different ports for
programming/wire based transmission and xbee transmission, so they are completly indepentend from each other. All we do is just changing the ports form 31/30 to 14/15.
the modules are configured corretly: 19200baud, no parity, single stop, packetization = 0 (characters are transmitted as they are received). We do not use any character
that could cause the module entering the "programming mode".
Still it does not work correctly... just a few seconds and then it freezes. I hope there is not to much wrong, as english is not my mother tongue.
Thank you.
Comments
but i am not sure , since i use the new xbee mesh2.5 bu for me
i had to set the address in the modules it self.
Use the Software from Digi to set x-CTU and set the DH and DL
In other words, you need to set the DH to the SH(Serial Number of the other module )
And also DL with SL from the other module.
And of course you need to do that for both modules.
So ech module knows where to send and recive from.
If you don't do it , the stream will stop or slow down.
Oh and don't forget to write
the +++ ATWR command after you made a change to the xbee.
Since there is also a bug what hangs the module if you dont do it after setting changes.
Also why are you running so low Baut rate, speed it .
I run my setup with with 115200 and send 15 bytes data to the copter and recive 98 bytes from the copter.
And that with 30fps. and a lost frame rate from about 0.001%
And alsoi can recommend setting the serialization packets to a bit higher than 0 i had the same mistake at first.
No i use on the remote side 15
and on the copter side 98.
And of course timing is so important.
Since i am in a simulay proejct , i am curius about how good is the idg 300.
since we are still unclear if to use the new ifg 650 instead.
Do you guys have a blog site on diydrones.com ??
two of them lying around and they have wire antennas directly soldered on. My series 2.5 modules are the
ones with sma connector. The series 1 do not need to be configured properly first... they are really plug and
play. But off course you can config them in various ways .. but they are easier to handle than the new series 2.5. (If you use them the first time)
What I've configured is the R0 "register" ... which we found out is causing troubles if not set correctly. As you also mentioned... zero was
not the right value to go for. Currently we're running the serialization (R0) at 1, standard value is 3 which was causing a lot of trouble... At the moment
it seems to work.. I hope that the serialization solved the problem.
The reason for slow datarates is just to ensure not to have another source that may cause problems. We'll increase
the speed later on when the problem is fixed. Changing mutiple parameters is always a bad thing
The IDG300 is a pretty nice sensor for the price... internal resonance frequency is somewhere around 15kHz which is a good thing to ensure proper
working in presence of motor vibrations... the ST Lisy300 for example, is almost useless for such projects as they stop working under influence
of vibration near their internal mechanical resonance frequency. I'd go for the idg500, as is has the same sensitivity like the idg300 but a higher
mechanical resoance frequency (aprox. 25kHz). In my opinion the idg650 has a to wide measuring range (+- 2000 °/s) which will result in very
low sensitivity. You will need a high adc resolution adc to measure the low rates also.. which is then a problem with noise and so on. That's why we've
choosen the adxl300 as z-rate gyro which has an +-300°/s measuring range.
We are currently testing many things on this very first prototype pcb to collect information, and gain in experience which will then help us for our
upcoming UAV projects. Where we'll use much more powerful hardware and more expensive hardware. We just like to test things like setting up
pd/pid controller, kalman filter and so on.
We already have our blog... currently there is just no time to do any external documentary work / publishing .. but in the next weeks we'll upload schematics, source
codes pictures and videos as well... (http://www.admirabilis.org) There is nothing online yet... just some testpages. You're welcome to have a look
at our site in a few weeks.
Post Edited (Steady) : 3/6/2009 8:17:58 PM GMT
but there are two outputs you can access simultaneously on the IDG650: the standard 2000 deg/s (0.5mV/°/s sensitivity) - and then the 440 deg/s (2.27mV/°/s sensitivity) on the 4.5_out amplified channel - wouldn't the amplified output give you a range close to the IDG500 @ 500 deg/s (2 mV/°/s sensitivity)? Or am I misunderstanding something?
>the ST Lisy300 for example, is almost useless for such projects as they stop working under influence of vibration near their internal mechanical resonance frequency
This is a good point and may be a problem with our IMU design since it has not been tested yet in a flying craft - I believe the resonance of the Lisy300 is 4.5 kHZ
What sort of resonances have you observed on a 4 or 6 rotor craft?
BTW, the 900 MHz Pro's seem to be a better XBee unit (throughput, range) than the 2.4GHz alternatives
I'm sorry! Yes, you're right... I forgot about the dual output! Sure, in this case you could prepare your hardware to use both output pins. That's off course the big advantage of the idg500/650.
I haven't yet measured resonance frequencies in our structure, but previous motor and sensor tests did not show any critical effect on our sensor signals. I've been reading/searching a lot, and had
a look at many different gyros as well as accelerometers. A few people on the german mikrocopter forum warned about the Lisy300's low resonance frequency. Those brushless motors are for sure
capable of causing vibrations in this frequency range. The mechanical design plays also a crucial role... best you try it your self and prove it wrong or right. I guess you're using the Lisy as Z rate?
Which would be in case not that dramatic for a quadrocopter/hexacopter.. whatever, as the x-y gyro play the most important role in such a vehicle.
Well, I also thought about those 900MHz modules... but I did not find a shop yet. They are for sure more reliable.
Thanks for the comments. Yes, z rate. This sensor is of course nice because it allows for a very compact 6DOF design - so, no perpendicular mounting concerns. I guess we'll have to be careful with this and test before making more than one pcb. I haven't seen the mikrokopter posts but we'll search for them, probably in German so Anubisbot will have to look this over. Perhaps you can isolate out the frequencies with a proper mount though (rubber washers?). I once had problems with loud noise from several large fans mounted in a structure and solved it by suspending them from bungee/rubber cords, and this worked nicely - if we notice our sensor is being washed out, maybe a rubber band mount might help dampen the vibrations...
Yes, they've been hard to find. Sparkfun just recently started selling the RPSMA version, or you can call Digi directly to order (no online ordering yet).