Joystick flying with ArduCopter
Awhile ago I promised a more postings and so here we go. I know that many of you have been waiting this fun to be true... Now it is.
One our friend came to visit today at jDrones and they wanted to see latest software and other improvements on the whole project so we went to our local flying area next to our office and started to play with our birds.
We tested different combinations from quads to hexas but most memorable moment for our guests was that when I started to fly without any RC controller. Just had Laptop, Joystick and XBee telemetry. Well what else you need?? :)
Ok I would not say that everyone should rush to it but this is a good start. We still need to solve several issues on failsafes and so on but we are close. All I can do is to give big hoooray to our development team on all the achievements that we have been done.
Video might be a bit shaky but so it the pilot (my second time to fly our hexas with joystick).
Have fun and we will be there......
Br,
Jani
Comments
Well, we had this discussion about esc updates before. The APM is updating the ESCs at a rate of 400hz, and with some ESCs, they can be reflashed to remove a low pass filter that's apparently built into them that'll allow them to respond to faster updates.
However from a joystick/human interface point of view, human beings would probably not be able to update the joystick faster than 100 hz/10ms. And beyond that the human operator won't be able to noticed the difference.
Ha ha, now we're really starting to get off topic for this thread. PM me any questions, and I'll try to send you the answers. Or open a new thread, if you think the discussion could be of interest to others. ;-)
BoBo, yes the APM is reading the input at 20hz, and Mission Planner is sending at 20hz as well. In fact, the packets are being sent every time the sender thread is woken up, which is every 50ms, and the new joystick positions were being read for each send. My mistake was thinking that the timer used in the setup screen was still being used for updating the joystick data, but in fact it was only used during setup.
Since the APM has limited CPU, we cannot increase the rate at which it reads input packets, without impacting flight performance, so increasing the send rate at the Mission Planner would not be suitable. And it's evident that the current 20hz send rate is sufficient for "real-time" response from joystick control anyway. Ideally for bullet proof real-time response, I'd like to see a 100hz (10ms) rate.
Well, if Jani doesn't mind, we can continue on this thread, otherwise we can move it to the other thread.
To answer a few of your questions:
1- Yes, the max bps over air for the APC220 is 19200, and over the serial link is 57600. So because of this, it's evident that increase in bandwidth is not necessary, if full duplex radios are used, achieved by using 4 modules.
2- In my tests, I used two different frequencies.(check out the diagram in the last page) However, because the APC has the ability to transmit on the same frequency, with different network addresses, it should also work with the same frequency as well, if different network id is used for out and incoming channels. This should be the same for xbee, as well. As with all transmission over shared media, there's always a chance of collisions, if there is simultaneous access.
3- Regarding the 20 updates per second I commented on, Michael pointed out to me that there was no issue, since I was looking at the wrong timer. The one I was looking at was only used in the Joystick configuration screen, and not the main transmit loop.
Actually, I was doing it with APC220 modules, which was running in the 400Mhz range. I'm not sure the 2.4ghz xbee will be any better. The issue is that the both the xbee and apc modules are single duplex. You're either transmitting or receiving. So, if the APM is sending telemetry, it could starve out your uplink control packets. The multi-module solution avoids the problem by enabling full duplex communication. Because of this, I don't think the increased band width will completely solve the problem.
Jani, what version code are you using?
Are you using the dual xbee solution, as we discussed in the below discussion, to get around the lag problem?
http://www.diydrones.com/profiles/blogs/flying-with-joystick?commen...
@BoBo Flight
My experience with speed/reliability is mostly experimental. But I can confirm that lower speed will translate into a greater reliability. Probably this has to do with duration of each bit in the square pulse train of the serial protocol. With short pulses there is a greater chance of irrecoverable loss of information. At least this is how I explain this to myself :) Also, don't take this statement very seriously, you can increase reliability by using approppriate communication protocols with error recovery, but this will translate into using more processing power.. which we usually don't have..
Jani, thanks for the extended reply!
@BoBo Flight - in my experience it would make sense to stay at 900 band for outdoors as it has less penetration but more pass-around - less packets are lost. As for connection speed it would make sense to switch to lower speed - 14400 or even 9600. Again, this will also affect reliability of the connection. Also, connection quality degrades more rapidly at longer distance.
Jani, what was a max distance to the vehicle while flying like that?
We did run Xbee 900 telemetry with 57600 Baud which is default for ArduCopter. As for latency I would say none till 0.5 seconds. All controls worked almost instantly. I think I noticed minor delay only once during whole flight and even that was really small eg did not affect on flying it self.
If there would be a lot of latency, it would affect a lot especially on landings. Landings are easy after you get hang of it..
Biggest challenge was to make small enough moves with Throttle as my throttle slider was without any "feel". We also need to have a lot on exposure on center stick areas.. Maybe even to rethink whole scaling of control commands.
As seen on video, after 30 secs or so I was able to fly it already rather nice.. First 30 secs are a bit jumpy due made too big throttle moves.. It's sensitive like Ferrari :)
For reliability we still need to work a lot more so BE EXTRA CAREFUL if you plan to do same thing with current softwares. As there are no failsafe for joystick control yet.
Range totally depends on telemetry modems that you use and also interference on your area. We have been using 900Mhz XBees 2 km ranges without any problem but that has been only for normal telemetry, would i go and start to fly with relying just for those now.. I would not do it yet and would suggest not to do it either. Let us to get failsafes for better before planning any longer flights.
But after all.. it was really fun to fly like that thou not easy as used to fly with RC radios... Maybe it will change in future.
Great job! Now, how reliable is this in terms of latency, bandwidth, number of droppped packets and number of control messages per second?
-
1
-
2
of 2 Next