2-way com with aurdu with GPS and in auto
I have just perfected (finally got to work) a method for sending data up to the plane while in auto and without missing a GPS frame. I've been using all my spare time for a week to get it.
It works by sharing the uart time wise. The U-blox sends data for ~28ms 4X /s. That leaves a lot of time to receive from the X-bee. The X-bee has a 256 byte buffer the will hold data until the ardu asks for it.
If the RTS(request to send) is not connected the data goes right through. If the RTS is held HIGH. the X-bee will hold the data packet until RTS goes LOW. Packets must be less than 256 bytes. No problem!
I connected the RTS to D7 on the ardu and the Tx from the X-bee goes to a diode to the ardu. Basiclly two diodes pointing away from each other and a 10 K pull up resistor. The cathode of the other diode goes to the GPS Tx. The middle goes to the ardu Rx. After the data is read from the GPS and the extra bytes in the 368 uart buffer are cleared (read and dumped), D7 is set low and the X-bee sends received data to the ardu, when that's done D7 goes HIGH again. I used Jordi's "decode" from the GS
in the ardu to read and process the received data. BTW I have a pretty good dual trace scope that I used to see what was going on. Impossible to debug without one. Will post more details and code later.I just now got it to work and have something I got to do right now. And I'am not using the shield, but it should work with one.
Update: This is a re-post of yesterdays topic, but under the right category.
Today I got it working without hoseing the UBLOX nav data. I was going into my read function after each UBLOX id. I think the UBLOX sends the entire class all at once and each id has its own chechsum. I forced the function to keep going until all the id fields used are read, then go on and read the X-bee. The stock version reads an id field and moves on and at the next call to it gets the next id end so on. After each id read I was dumping the rest of the needed data except for the nav_status I think. With this flaw I never lost the blue lock led, just got all zeros for the data or the data froze as is. After some more thurough testing/de-bugging I will post the code modifications if any one is interested.
It works by sharing the uart time wise. The U-blox sends data for ~28ms 4X /s. That leaves a lot of time to receive from the X-bee. The X-bee has a 256 byte buffer the will hold data until the ardu asks for it.
If the RTS(request to send) is not connected the data goes right through. If the RTS is held HIGH. the X-bee will hold the data packet until RTS goes LOW. Packets must be less than 256 bytes. No problem!
I connected the RTS to D7 on the ardu and the Tx from the X-bee goes to a diode to the ardu. Basiclly two diodes pointing away from each other and a 10 K pull up resistor. The cathode of the other diode goes to the GPS Tx. The middle goes to the ardu Rx. After the data is read from the GPS and the extra bytes in the 368 uart buffer are cleared (read and dumped), D7 is set low and the X-bee sends received data to the ardu, when that's done D7 goes HIGH again. I used Jordi's "decode" from the GS
in the ardu to read and process the received data. BTW I have a pretty good dual trace scope that I used to see what was going on. Impossible to debug without one. Will post more details and code later.I just now got it to work and have something I got to do right now. And I'am not using the shield, but it should work with one.
Update: This is a re-post of yesterdays topic, but under the right category.
Today I got it working without hoseing the UBLOX nav data. I was going into my read function after each UBLOX id. I think the UBLOX sends the entire class all at once and each id has its own chechsum. I forced the function to keep going until all the id fields used are read, then go on and read the X-bee. The stock version reads an id field and moves on and at the next call to it gets the next id end so on. After each id read I was dumping the rest of the needed data except for the nav_status I think. With this flaw I never lost the blue lock led, just got all zeros for the data or the data froze as is. After some more thurough testing/de-bugging I will post the code modifications if any one is interested.
- Attachments:
-
-
Com connect.bmp, 729 KB
-
Replies to This Discussion
-
Permalink Reply by Earl on -
I am defiantly interested ! What I would like to use it for is sending commands to the plane to :
1. Skip to next waypoint
2. Go to waypoint xx.
3. Circle where you are at.
4. Decend to xxxx altitude and hold
5. Assend to xxxx altitude and hold
6. Set max turn to xx degrees
7. Come home
8. Do saved course 1,2,3
9. Other functions along this line.....
All on a menu screen on the ardustation by pushing a button. Depending on which function you select by a cursor or reversed lettering, it may ask you for more parameters. Then it send coded commands to the ardupilot in 256 byte chunks or less by pushing a 'go' button on the ardustation !
This opens up a WHOLE lot of new things we could do with the ardupilot as we have some program storage to still be used in the ardupilot. (About 14k yet I think)
Also a lot of room in the ardustation to use also.
Count me in....
Earl
-
DeveloperPermalink Reply by jasonshort on -
Can you post a diagram of your circuit? I might try that using Pin 6 and 7 and use the Serial mux to control it all. Your circuit sounds like it would save me a pin. Maybe the next Ardupilot board will incorporate these features... hint, hint.
-
Permalink Reply by Earl on
-
I think it is 2 diodes and a resistor on the ardupilot board. The ardustation board remains unchanged for hardware.
ArduPilot and ArduStation SOFTWARE would need to be modified for these features.
Greg found a method with a MINIMAL hardware change, we could send data FROM the ArduStation via the XBee radio, UP to the ArduPilot.
This is a MAJOR breakthrough as far as I am concerned.
Quite ingenious to use the XBee buffer to RX the data until the AutoPilot RX ACKS the reception and signals the ArduStation that the command was received
This REALLY does open up a LOT of possibilities !
THANKS Greg, there is a lot of us that will help on the software I'm sure.
Earl
-
ModeratorPermalink Reply by Dr Mike Black on -
With Earl on this,
Happy to offer my limited LV software skills on this, but your GS is very very nice,,,,
2way coms on a single board is def the way forward, ....as i posted yesterday....well done..
regards.
mike
-
Permalink Reply by Earl on
-
Here I changed the Ardustation display code.....
I also changed R11 from 330 ohm to a 3.3K resistor because the blue LED was WAY to bright. Now it is just right.
Here is the new code I made for the display on the ArduStation if anyone is interested.
Here is the 2 files I changed.
Also the readings are in FEET not meters. I have a hard time doing meters.
Earl - Attachments:
-
-
ArduStation_V31_Feet_6Screen.pde, 10 KB
-
Decode.pde, 3 KB
-
-
Permalink Reply by Greg Fletcher on -
I am still working at it. I was going to buckle down on the code wanted to get the hardware ready, so i took my mess of clipleads and re-did my little breadboard with switches & such. It was late and I was tired. Once again I have spent time tracking down a self-created bug. The gray wire is pin 6 on the schematic not pin 1 as i a**umed.
Strange thing is, the UBLX was still sending "data" at the same rate/period.? Saw it on the scope and it really thru me off. Never make a simple hardware change with a code change without testing in between DAAAH!
any how I'm tired now and will continue in the morning. Earl, this does work. I tried to send a bitmap image of the wiring, but it didn't work :(
-
Permalink Reply by Earl on
-
Greg, are you doing the send up to the AP from the Groundstation running on a laptop or from the ArduStation small hardware box ??
Earl
-
Permalink Reply by Greg Fletcher on
-
Aurdu station box.
-
Permalink Reply by Earl on
-
Send it as a picture up close.
Also see my post on the new display SW i Posted
Earl - Attachments:
-
-
GroundStation 007.jpg, 617 KB
-
-
Permalink Reply by Greg Fletcher on
-
This will do for now.
-
Permalink Reply by Greg Fletcher on
-
- Attachments:
-
-
IMG_0813.JPG, 506 KB
-
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The third round was a reliablilty/aerial photography round for both planes and copters, which is now closed. Stay tuned for the next round, beginning soon.A list of all T3 contests is here.
Top Content
Groups
-
DIYDrones - CNC Project
61 members
-
Moderators
57 members
-
ArduPilot (legacy) User …
95 members
-
ArduCopter Evolution Team
108 members
-
ArduCopter User Group
617 members
© 2012 Created by Chris Anderson.
