I tried following today on 2.0.49 firmware with APM Planner 1.0.86. As you can see from the video, there was obvious lag in the command around 1/2 seconds. The other thing the quad was doing it was not coming to stabilize position when I centered the joystick. This is because of the uneven cushion I placed above table. The settings are
Joystick: Saitek Cyborg
Telemetry: 900Mhz xbees @ 57600bps link speed
frame gaui 500X
Joystick is pretty slow to respond. When I checked in windows game controller I found out that in game controller calibration looking at the raw data the joystick response is slow. So its a windows + PC issue
Comments
I know I was the one that suggested the duplex solution but I have recently discovered something else that warrants further investigation should anyone have time spare.
I've been working on advanced serial tools for the Arduino Visual Studio plugin and in doing so, found that reading the inbound windows serial stream prevents the outbound from being sent by windows. In joystick terms this might prevent commands from being sent to the micro controller in a timely manner.
I altered my serial reader to check the Serial.BytesToWrite property. If > 0 then the reader exits without reading any inbound data enabling windows to send the commands to the mc. Windows buffers the inbound data so we don't loose anything. In reality, if the joystick commands are sent at controlled intervals such as 4 or 5 hz then the reader doesn't have to exit many times and smooth data receive continues.
Summary: I think it's worth tweaking the windows GCS to implement this system and to see if joystick control then works using single xbees. It might not help xbee900 users who work at slow data rates but 2.4 users might be pleasantly surprised. 2.4 xbees send and receive at 250k so there should be plenty of band width.
From the joystick control pov, I've artificially limited the control packet updates to 19.2kbps, and the motors are still responsive. Realistically to get realtime response, we really only need about 10hz. If there is a case to be made to increase the communication speed, we could use faster modems, and configure for higher baud rates. However, my opinion is that any excess power on the controller should be used for flight control, and stabilization, rather than communications. But, we'll see what develops in the future. We may have some need for drone to drone communications, such as coordinating swarm behaviour in the near future. But, as I mentioned in the other discussion, once we get into asynchonous communications, we have to start worrying about packet loss/resend, and out of ordering of packets. Not a trivial task without dedicated link layer support.
if i remeber well the maximum data rate for a serial port is 115 kbps, so c.a. 11 KB/S the problem then is the comunication between xbee and serial port of APM, it's really cool if in the next version of Arduino (based on Cortex arch)the team can put a serial port with the velocity of 2 Mbps, for example the tencology that use a serial interface as the Cisco wic 1t i think that can be integrated with some effort .
if we have a serial port at this "high" speed rate we can connect evry type of wirless modem .
I just read this whole post with all of the comments. Excellent! You guys did all of the calculations of the needed bandwidth which eventually led you to do two units on each end. However, I think you were working with 900 back then. Since 2.4Ghz has so much more bandwidth(256K according to spec sheet, right?), does that mean that it is not necessary to have two if working with 2.4Ghz? Obviously range would be affected with 2.4, but that can be fine for some people. I saw #Top Cat# said he used 2.4, but I am not sure if he was just using 1 or 2.
Also, to some other people's comments on "why" ... I think that this opens up the door for a lot of cool stuff. One example -- someone could theoretically have the pc send a pre-programmed macro/program of commands to the copter (as if it were coming from an rc controller) for the copter to replicate a complicated aerial maneuver (flips, rolls, etc.). It would be cool to be able to push one button and have your copter do a flip by itself :) ... obviously, that is perhaps a little "visionary", but it gives some ideas to having a "real-time" control via a pc instead of a standard rc setup.
I am very intersted to see this "enhanced" or pushed further. Anyone up for dual 2.4Ghz transmitters? :) ... probably complete overkill on the bandwidth and unnecessary ... but I just smile :).
A special shout out to Fab and Ellison!!! Fab thought of two to test out the badnwidth and Ellison brought this home! Great job!
good news. then here is a tip for all 2.4 users. when soldering oilpan headers use an extended header for the ftdi pins. that's a header with a female one side and extended male pins on the other. this will give you some pins above the oil pan thata 2nd xbee can connect to. usb will still work it is just that we get better access to the pins. there needs to be some code changes to support this for joystick so our simple test described above is for most people., however at 56k, apm1280 users will find that they can compile and upload new apm code using the xbee attached to the ftdi. there is a small solder required on the xbee board to connect D3 but this is well documented on arduino.cc
so we have two choices, simple quick fix for joystick or more comprehensive dual xbee system that allows wireless program and also allows for a fall back fail safe should the main radio signal fail. i hope this makes sense.
just tried with 2.4 xbee and it works GREAT!
Ok, here's a couple of diagrams. I'll do a little write up later on. The idea is to circumvent the motor control delays due to the bandwidth limitations of the non-duplex nature of the various wireless telemetry link. (Xbee and APC220)
couple of other quick notes. if i recall, fastserial3 (telemetry) can be defined as 0 instead of 3 by changing one line of code. the method of using xbee and usb on 0 is the default for the smaller arduino 328 chip that only has serial0. So this is why this is well tried and tested in other arduino projects.
Yes but it there is no reason why telemetry doesn't use 0 instead of 3 or if you want a quick fix then joystick on 0. If I recall the diyd xbee board has a switch for xbee/usb but this has been done many times with different arduino projects. At the worst you would unplug xbee when pc is connected
Fab, you mean Serial0? That's being used by the FTDI for the USB isn't it?
-
1
-
2
-
3
-
4
-
5
of 12 Next