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
Sorry to ask this basic question: do you still need to have an RC on your arducopter to be able to solely control it with a joystick? The point is I bought a ready-to-fly one but without RC, and now been having trouble flying it just via Joystick->Xbee->Arducopter. In my search, I came across this note in the WiKi saying:
"... note that you must be under autopilot control for them to take effect."
Does this mean having an RC is mandatory to start with?
I appreciate any comment on this. Thanks.
Thanks Ellison. I was not aware of that ESC discussion taking place within this thought process. It is hard for me to keep track of all the discussions that have taken place in each forum. I posted it because I think it is a pertitent item to have in mind with this discussion of flying with a joystick.
The rest of this response is not a disagreement with you, but a futher clarification of my previous point.
My main point is that there are a lot of components (ESCs included) that all need to be changed so that a 50ms or more ideally a 10ms response rate is achieved. Changing just one or a few will do nothing if there is a bottleneck anywhere between user input and drone response. ESCs definately seem to be one spot that people might (and have in the past) forget.
I don't think that a common setup for APM2 would even provide a 50ms overall input to response today. I think that is the first milestone that needs to be achieved and move it towards 10ms.
I currently agree that 10ms is probably my target. I don't think I would necessarily even try to get it faster because I do agree that it might not make that much of a difference. However, a few fun facts and things that I was considering -- Air Force pilots have been tested to identify (not just notice, but identify object) flashed less than 5ms (not that many of us are air force pilots -- but we pretend to be probably). You can roughly test your own to notice (not identify) by setting an led to flash every __ ms. Once the light seems to always be on, you have surpassed your ability to see it blink (One reason for a higher TV hz setting).
Also, it is not just about a pilot noticing the difference or updating a joystick faster. It is more about an input turning into action within a quick enough timeframe. The slowest part in the whole set up is probably the actual mechanical process and not the electrical/computer process -- the motors have to adjust their speed so that the thrust from the props adjust. However, you want to give the props updates on required thrust as fast as possible so that it can be as less behind as possible.
Lastly, while this thread is more about user control ... my response time comments include more than just this thread. The drone needs to take action must faster than human input. An example is the auto hover (or any auto command). The input is not human but sensors (gyros, etc.). With faster than human input, the response needs to be brought closer to the timeframe of the input. Again, the slowest response is probably the actual motors/propellors but that doesn't mean that they should not have updated information even faster than they can completely respond.
Again, I do not say this because I disagree with your comment. Your comment does not seem to be in conflict. I am just trying to reclarify my post/ideas.
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.
:) ... yeeeaaahhhhh :) ... I will do that. I will try to think of the best way to do each question to have it organized and be helpful to others. If I open a new thread (likely), I will make sure that I PM you the link so that I can get some input. I am not just trying to boost your ego. I have read a lot of blogs (on DIYDrones and others) and worked with a lot of technical teams in my professional life -- I think you are a semi-rare find of knowledge and helpfulness being combined together. I really appreciate it.
Thanks again!
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. ;-)
Thank you Ellison! I am of the same understanding now. We agree that it is currently at 50ms. However, due to limited resources on the APM (CPU) we should not make it a shorter interval and it also seems sufficient for now. With APM 2.0 and the sensors having its own processor, there should be some extra processing power available. If not then, I would expect that when Arduino switches to ARM that there will be a VERY significant jump in processing power (ARM should FINALLY bring Arduino more into the "new age").
I was looking for your perspective on a more ideal rate -- and you confirmed 10ms. That is great - thank you. So maybe once we have some processing power to spare, this would be one area to try out to even get an even more awesome rate.
This makes me curious for a comparison. When a copter is in alt-hold or loiter or such functions, how often is it polling the sensors and taking action? Is it 50ms? Is it faster or slower? How often is telemetry sending data? Does reception/processing of the standard rc commands have anything to which we can compare this to? Not necessarily super important in this discussion, but I think that these types of things might give us an interesting comparison with the joystick sending timeframe. I will try to look, but I can guarantee you that you or someone else could find it faster.
Lastly, I was looking at your diagram more. You have the Oilpan in your diagram. I am still getting familiar with APM 2.0, but I think that it does not have the OilPan anymore. Does this change things? Also, a really basic question -- how did you connect the wires? Did you actually solder them or did you use some other method? Another basic question related to your diagram -- is there a certain USB to Serial adapter that you prefer or are they all the same (quality, function, etc)? For example, I am not sure if there is one that has an option of using one or two USB ports to potentially deliver more power to items that might need it ... or some other feature with a USB to Serial adapter. While I have used them, I can tell by your posts that you could teach me a ton about all of these items and I could EASILY be missing out on something. I wish you could be my tutor :). (Wait -- you are right now!! I just want it even moreso!!!)
Thank you for all of your time! :)
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.
@Ellison -- Thank you for your post. #1 and #2 -- makes sense. Thank you for the clarification. #3 -- I am still not of the same understanding. The way that I read the comment thread, the wrong timer you were looking at was the 100ms one that is used for the setup screen. Michael said "APM planner send joystick packets at 20hz ie every 50 ms". I agree that you found out that this was not the root of the issue. However, it still does seem to be every 50ms. How am I misreading his comment? If it is at 50ms, would you want to make it faster (shorter interval)?
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.
-
1
-
2
-
3
-
4
of 4 Next