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
@Ellison - yes, I have been concerned with impacting the sensors, but my initial sense was that given the relatively slow timing loops and the specifics of my plan it should be ok. I wanted to look at dumping only one MAVlink stream on the i2c bus, and having the telemetry proxy/compressor send and receive, while the OSD module (which I was going to try to combine, until I looked at the very tight timing loops for the more simple hardware OSDs like DIYOSD) would simply listen in. Then I figured that most of everything an RTOS ROS would want to know would also be in the MAVlink stream, so that could listen in also. In the end, my thinking is that I would add very little extra (some specialized and infrequent control/status messages to/from) except the single mavlink stream. But I have always assumed that our i2c is standard mode or better, and I haven't done the math yet to see if my wag is ok.
Ahem ok - well that's a blow.
Can be somewhat mitigated in software right now however - Most of the downlink traffic are data streams which are requested by the planner - to drive the HUD etc. These data rate for these streams are configurable. Non essential streams (eg perhaps the GPS status) could be dialled right back to 1Hz or less.
Sounding more and more like XBee API mode should be considered to improve matters in any substantive way!
@Andrew - it has always been my understanding that Xbee are not full duplex (radio link side) although I have not validated that across all models
@Mike
Yes, from an engineering point of view, I2C for telemetry would be inexpensive, but from a practical standpoint, there are no cheap and sufficiently long range I2C wireless links and many people have invested in expensive Xbees for the purpose of doing telemetry.
Also from an engineering standpoint, although I2C supports 128 devices, being a bus, the more devices you put on it, the more chance of collisions on the bus, and thus a reduction in speed. Since critical flight sensors are now on the bus, we don't want them to start slowing done because of the need to send telemetry, which in reality is not that critical a system. A few loss packets of telemetry is ok, but any collision causing a missed sensor update can have major impact on flight control.
@Simon Heh I know what you mean. Well as soon as DIYD starts doing swarming quads - I will look forward to your help ;-)
any my apologies to my fellow members, I have a lot of ideas, and more than half of them are wrong, which I only discover when I finally get to trying it, and realize my mistakes... which takes forever, since I am always behind my plans :)
@Andrew - I'm in the same position as all of us here, I can take my XBees and start fooling around with them and a MAVLink, or can fool around with something else ;)
I'm not sure I have time for this now, but I like the idea. At some point, if it won't get implemented I'll look into this.
@ellison - well, my thinking is this. i2c is inexpensive, because 1) we are already using/compiling the wire lib for the magnetometer and 2) the protocol supports .... is it 128 devices? something like that. And many devices we use support i2c... consider the excellent offloading of sonar to a mini that uses PWM rather than analog. It can do this because if it blocks, it is no big deal. If the APM blocks... err... falling brick. I was working on an i2c OSD also. But why go through the (relatively minor) effort to move the telemetry off of the TTL, where it has a perfectly happy home right now? Because TTL is a very valuable interface, and even after so many years, it remains the primary integration interface for micro and not-so-micro systems. If we can free up even one TTL interface for expansion (and yes, I know we can do TTL in software, but I think it has a not so good impact on the APM's loops? I'm not sure) then we support what this community is about.... not building the *same* UAV over and over, but building the ArduPlane/ArduCopter, then expanding it in many different ways.
Many other systems (lidar, rfid, laser display, RTOS ROS on a gumstix for behavior) use TTL, and many do not have i2c. So I think it might benefit us to free up even just one TTL, make it easier for people to add their special device to their flying platform.
@Simon - are you in a position to push this forward? I'd love to see that as an investigation made by the dev team. The XBees are really expensive for what they do - and I'd love to see us get the best use out of them!
@Ellison - I can almost guarantee it would do packet ordering in 'transparent link' mode. Otherwise that would make for a pretty useless 'virtual serial cable' which is what it is touted as.
I've never looked at the data sheet though.
I agree with you - the flight control packets should be dropped if they are late - as they are useless. My point is though I'm not sure that's what's happenning now
-
4
-
5
-
6
-
7
-
8
of 12 Next