Joystick fun @ jDrones airfield with ArduCopter

BoBo Flight December 21, 2011 at 7:25pm

@Ellison -- Thank you for your response. I am not sure if I should post here or in that other thread, but I will follow your lead. If I remember reading your comments in the other thread, you did your tests on the APC220 over wire because the 400Mhz would not do 56K even when you had a total of 4 to run full duplex. Was that right? What is the rate that the 400Mhz runs at (I thought you said 19200 bps)? What I am trying to get at is ... if we do have full duplex (2 sets), then what is the maximum rate of each thing that may go through each link(telemetry, controls, etc.) = how much transmission speed you need for uplink and downlink = what frequencies might work for each. I saw Michael Oborne post on the needed data for some things -- joystick 24 bytes * 20 = 480 bps ... is the 20 the number of transmissions per second, then? I think this makes sense because he also posted that it is at 50ms. In one comment, you had said that you would want to bring that down to under 10ms for real time response. Do you still stand by that comment? Now that you have tried the duplex method to solve the core latency issue, have you tried to lower the transmission interval to be 10 ms or lower? This would take up more bandwidth, but at 480bps, it seems like you have plenty to spare and this might give it more responsiveness. What do you think?

Also, your answer made me question my question even more in the other post. Wouldn't having 4 (2 sets) of transmitters on the same frequency cause interference issues too? Wouldn't the sending of one technically interferre with the sending of the other. By having 4, I understand that you solved the latency because the joystick command essentially does not have to wait for telemetry to be finished. However, if they are both transmitting the same time on the same frequency, won't you have interference issues (supposedly moreso with lower frequencies than 2.4Ghz -- lots of things run together with 2.4Ghz already because the transmitters can be "paired" to each other -- wireless phones, wifi, etc.)?

If so, I would think someone might want to send the commands (uplink) using a lower frequency (greater distance, less data needed?) and have the telemetry (downlink) use a higher frequency (less distance, more data needed?). Using XBees, probably 900MHz uplink and 2.4Ghz downlink. In this manner, your telemetry will cut out before you lose command of the copter/plane.

Interested in your thoughts.

Ellison Chan December 21, 2011 at 5:28pm

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.

BoBo Flight December 21, 2011 at 4:59pm

Thank you Ellison for that post. I had no idea about that other thread! I will post there too! Thanks again!!!

Ellison Chan December 21, 2011 at 3:07pm

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 December 21, 2011 at 2:49pm

@Roman

Thank you for your response. Good insight and thank you for the explanation of the reliability.

I agree that most high reliability protocals require some extra "lost packets" logic or error recovery and therefore need more processing power. This is definately the case for probably the widest used protocols today for "internet" usage (TCP, UDP, etc). I also agree that APM 1.0 had its processsing more on the maxed out end. However, I think that APM 2.0 is much better and once Arduino switches to ARM (1Q12), I think the processor will get a very significant upgrade. I also think that the processor upgrade timelines will condense once they move to ARM since this is much more industry standard. On top of that, the RTOS should be right behind these better processors. What I am trying to say is that I think the landscape is changing very quickly and that the extra processing power should be there within short order. While Arduino and APM are both already very COOL, I think these type of core changes are needed to bring them both closer to "everyday specs" instead of "yesterday's specs" (I mean this with 0 disrespect). And with that change, I personally think that one of the main places this extra power should be used is in "upgrading" the communication channel between the drone and the control station. I think standard RC is pretty archaic compared to what the world does today with communications.

Take this even further to something maybe much more impractical and far away ... but it would be cool if the government would open up a very small portion of the HUSPA bands (cell phones) for hobby use and if we had the open technology to really be able to communicate over this spectrum. Could you imagine a DIRECT line (Not through the internet - this has been done) to your plane or copter with around 13Mb/sec of very low latency communications? Also, with these protocols you could have people going over the same channel/frequency and not interfere with each other (unlike standard RC). That would all be insane. This is a little more far fetched ... but I think there are plenty of stepping stones to start heading in that direction.

All in good time, I guess.

Roman Krashanitsa December 21, 2011 at 2:30pm

@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..

BoBo Flight December 21, 2011 at 1:48pm

Yes, that is 100% correct -- absolutely 0 modification to the controller to get it talking to a pc. If you look up "MotionJoy", there is a lot of documentation. Essentially, you need to have BlueTooth on your computer. The MotionJoy dev recommends a certain one and I recommend just getting that ... other ones can have problems and it is pretty cheap ... so just better to get it. You then install all the drivers ... and get the MotionJoy software. Once you have the software, you hook up the controller to the computer via cable and use the software to "pair" it to the computer. Once paired, you can unhook the cable and do it over bluetooth. You can then set up a variety of controller profiles where you tell it what you want every single button to do. For example you can have the right trigger button simulate typing "Y" on the keyboard. Very flexible. I use it all the time to play computer games with the PS3 controller when the games do not natively support the controller. It is very cool. You can set up the joystick axis buttons to be act like a mouse and/or keyboard buttons. It makes it so that EVERY PC game is PS3 compatible and you can set up ANY button setup that you like. Even games that support the PS3 controller, I will sometimes do this because I like a different button setup.

To apply this to Arducopter should be seamless. As long as he has the pc to copter setup ... then whether he pushes X on the keyboard to do something or you push something on the PS3 controller to simulate "X" being pushed ... that piece should be completely seemless.

I hope that helped to clear it up. Let me know if I left something out or was unclear. Thanks!

David Roberts December 21, 2011 at 1:41pm

I take it an XBox/PS controller would also work without modification?

BoBo Flight December 15, 2011 at 1:13pm

@Roman

Thanks Roman for the comment. I agree with the fact that the 900 band generally does better outdoors. Is there some reason why standard rc at a certain frequency is seen as more reliable than the XBee connection at the same frequency? If it is the same frequency, wouldn't there be the same reception/data loss issues either way? I feel like I have a significant gap in my understanding of the wireless data transmissions.

Can you explain further why you would lower the speed? Are you saying that it would increase the reliability of each command?

I am basically very confused how standard rc and this can be at the same frequency but experience a significant difference in results. What is the factor that makes them so different? This is probably a very deep question. (Is it merely that the standard rc doesn't have to process as much -- just some instruction over a CERTAIN channel ... whereas the XBee is a digital command that has to be processed) ... this seems like a silly reason because the flight controller has to interpret either command either way. Maybe once this is moved to a RTOS, it would be improved? I don't know .... but I sure am interested!

Roman Krashanitsa December 15, 2011 at 12:20pm

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?

Blogs

Joystick fun @ jDrones airfield with ArduCopter

Comments