Jump to content


Photo

Modelling a multirotor


  • Please log in to reply
35 replies to this topic

#1 w4Rd3n

w4Rd3n

    Advanced Member

  • Members
  • PipPipPip
  • 122 posts
  • Country: flag of Switzerland Switzerland


Posted 27 January 2012 - 01:08 PM

Hello.

is the bluetooth link capable to graph the behavior of the gyros during a testhover?
if yes, how fast resp. what is the sampling rate on it?

with this it should be possible to better approximate the Transfer function of a multirotor. the axes can be tested with a step change and then analyze the step response.
once the function is known it should be fairly easy to tune the pid and also say simple feedforward.

best

#2 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1912 posts
  • Country: flag of Germany Germany


Posted 27 January 2012 - 04:54 PM

is the bluetooth link capable to graph the behavior of the gyros during a testhover?
if yes, how fast resp. what is the sampling rate on it?


Yes, that's possible. I don't know exactly where the limit is. It depends on the speed of the serial connection (I'd recommend 115200 baud) and how fast the GCS can handle the incoming data on your machine. 10Hz update rate is no problem, I guess the limit is somewhere above 20-50Hz.

#3 Brian

Brian

    RF Lead Developer

  • Members
  • PipPipPip
  • 1472 posts
  • LocationTucson, AZ
  • Country: flag of United States United States


Posted 27 January 2012 - 05:55 PM

If I'm looking at the code correctly, the update rate on reading the sensors is every 2ms, or 500Hz. With 12 bits per sample and 6 samples, that would require 36kbps, so it seems like it would be possible.


#4 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 27 January 2012 - 05:58 PM

I think unfortunately it's right in the limit of where it's not feasible. When I set telemetry up for 50 hz updates they tend to burst. This is probably an issue with the telemetry scheduler but to map the response time I think you'd really need to be robustly > 50 Hz. On Revo it has a Spi port and I'm working on an Overo carrier for doing exactly these sort of things. My pet curiosity is on some adaptive control so stay tuned.

In truth though, PID tuning is pretty trivial for multirotors once you've done it a few times - and I bet what people like is fairly far from what a computer would say based on minimizing MSE. This is because people hate wobble and overshoot when flying but this is a natural part of getting the BW maximized.

If I'm looking at the code correctly, the update rate on reading the sensors is every 2ms, or 500Hz. With 12 bits per sample and 6 samples, that would require 36kbps, so it seems like it would be possible.


That's a good point Brian - I've definitely done logging that way for testing with custom streaming code and it works fairly well (although I normally fly around with a USB cable in this case :D). I haven't tried bit packing though, and you forget you normally have to add some sync and timing information to use the data well if your link isn't bulletproof. Normally for good logs it takes 115200 in my experience.
Testing crumple zones

#5 Brian

Brian

    RF Lead Developer

  • Members
  • PipPipPip
  • 1472 posts
  • LocationTucson, AZ
  • Country: flag of United States United States


Posted 27 January 2012 - 06:38 PM

That's a good point Brian - I've definitely done logging that way for testing with custom streaming code and it works fairly well (although I normally fly around with a USB cable in this case :D). I haven't tried bit packing though, and you forget you normally have to add some sync and timing information to use the data well if your link isn't bulletproof. Normally for good logs it takes 115200 in my experience.


I know I was being optimistic. The wireless link also has overhead, so you would have to make sure it was packetized well.

Have you seen these? They also use an SPI link, and are supposedly capable of 2Mbps at shorter ranges and 250kbps at longer ranges. I don't know what the PiPX uses currently, but I was thinking these might be good if we ever wanted to build a 2.4GHz version. You can get basic breakout boards on Ebay for dirt cheap, and I was thinking about getting a couple to see how good they are.

Of course, the Overo is a great idea as well, especially if it has wifi so that you can do data analysis while it's flying! We flew a Pandaboard on a quad and was able to login via ssh over wifi while it was in the air, so it is possible.

#6 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1912 posts
  • Country: flag of Germany Germany


Posted 27 January 2012 - 07:05 PM

If I'm looking at the code correctly, the update rate on reading the sensors is every 2ms, or 500Hz. With 12 bits per sample and 6 samples, that would require 36kbps, so it seems like it would be possible.


With the current code, the update rate can only be modified for a full UAVObject, AttitudeRaw in this case. This includes mags and accels so it's a fair amout of data. If I remember right (not shure about this), AttitudeRaw updates at 50Hz nearly saturate a 115kBaud link. Btw. is there anything that speaks against raising the 115kBaud limit on the serial ports?


In truth though, PID tuning is pretty trivial for multirotors once you've done it a few times - and I bet what people like is fairly far from what a computer would say based on minimizing MSE. This is because people hate wobble and overshoot when flying but this is a natural part of getting the BW maximized.


While I personally think the same, there are people out there that still have the impression that all this tuning stuff is way to complicate. They don't know and don't care what a control loop or PID is, the just want a perfectly flighing quad. An adaptive control with one or two simple sliders like "friendly <----> aggressive" would really be nice for them (and probably fun to implement :-)


They also use an SPI link, and are supposedly capable of 2Mbps at shorter ranges and 250kbps at longer ranges.


This should also be possible with Bluetooth, though many serial BT modules are limited to 460 or 920KBaud.

#7 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 27 January 2012 - 07:09 PM

They don't know and don't care what a control loop or PID is, the just want a perfectly flighing quad. An adaptive control with one or two simple sliders like "friendly <----> aggressive" would really be nice for them (and probably fun to implement :-)


Dadocorp is working on this to convert to sliders. The RateKp setting is 80% of that although then the AttitudeKp is required. Either way I'm glad my stubborn persistence of exposing the real settings has resulted in more people understanding what it is against their will :D
Testing crumple zones

#8 w4Rd3n

w4Rd3n

    Advanced Member

  • Members
  • PipPipPip
  • 122 posts
  • Country: flag of Switzerland Switzerland


Posted 27 January 2012 - 07:42 PM

maybe you are right ;)
anyway it would be great to have a link which is not so limited in range like bluetooth.
for me it could also be just onboard data logging and then when landed, transfer the data via bluetooth / cable to a pc.

Edited by w4Rd3n, 27 January 2012 - 07:46 PM.


#9 Guest_dankers_*

Guest_dankers_*
  • Guests

Posted 27 January 2012 - 08:37 PM

Either way I'm glad my stubborn persistence of exposing the real settings has resulted in more people understanding what it is against their will :D


It has also resulted in people saying we are too complex to use as well, while I agree education is great, we must be careful in not assuming people's intelligence compared to a future Phd. and also not underestimating their laziness!!

I have had a guy return a board to me because "It looks too complicated", I tried to assure him it was not in the end I took it back and suggested he went to a KK board, which he then bought and then flew. While we won't get as simple as a KK of course, we also don't help the situation.

I had to watch your PID tuning video twice and even then had to seek out simpler explanations elsewhere before I understood it fully. I still see many people on the forums going at it all wrong, I get embarrassed when we tell people 0.002 and not a integer value or a % and I get other messages like "Why do I need a chair to tune CC when other platforms don't".

So, that is the level we need to think about, people genuinely think they need a chair to be able to set up a CC. In fact, I have a new phase "Please think of the chair people".

#10 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1912 posts
  • Country: flag of Germany Germany


Posted 27 January 2012 - 10:41 PM

anyway it would be great to have a link which is not so limited in range like bluetooth.


What range do you need? I use a class 1 module together with a class 1 BT stick and stopped the range test at about 600m :).


I still see many people on the forums going at it all wrong, I get embarrassed when we tell people 0.002 and not a integer value or a % and I get other messages like "Why do I need a chair to tune CC when other platforms don't".


Well, a % value simply doesn't make sense - 50% of what? Scaling up the numbers to make them more readable could be an option - what about 2.1 (*10^-3) instead of 0.0021? Hmm.. okay, the 10^-3 would probably scare people even more...
As a long-term solution, I see two possible ways:

- Automatic "offline" tuning (evaluating flight logs in GCS and compute PID parameters to match some simple, adjustable parameters like response time or overshoot)
- Adaptive control loops (running on the flight controler and constantly adapts the PID parameters)

I'd prefer the second one as it has nice additional benefits, e.g. better adapts to different conditions like wind or changing weight (think with/without camera or if a payload has to be dropped during flight).

Btw, has anyone already used the Scicoslab and the Arkscicos toolbox? Their quad simulation looks nice but I don't know how realistic it is. I installed Scicoslab last weekend but have some trouble with the toolbox because it targets Linux and doesn't install out of the box on Win. I'll probably give it a try on OSX or install Debian somewhere...

#11 Guest_dankers_*

Guest_dankers_*
  • Guests

Posted 28 January 2012 - 12:01 AM

Well, a % value simply doesn't make sense - 50% of what? Scaling up the numbers to make them more readable could be an option - what about 2.1 (*10^-3) instead of 0.0021? Hmm.. okay, the 10^-3 would probably scare people even more...
As a long-term solution, I see two possible ways:


I tried that, lost that one as well, I'll add you to the PM if you wish and want to help with the GUI? Reddog and Mike wanted percent, I wanted a number 1 to 20, maybe 1 to 15 is better and in normal language multiple the existing by 1000. Worse with the percent is if we change the ranges in a firmware revision, the meaning of the percent changes and all the past settings we have posted on the wiki become worthless, but by scaling up, it still makes sense.

My main concern is to not bike shed it, the UI changes has been needed for so long and getting caught up and arguing the details like that just delays something getting done. Then if everyone complains about % being wrong in the review (likely), we fix it but at least we fix it when we are 99% there, not get caught up in debating details like that before anything is even written. No chance James would let percent through which is what I stated and what he said himself.

Adaptive control loops (running on the flight controler and constantly adapts the PID parameters)


Corvus is working on it, James also had it planned. It will get done I think as it is needed.

#12 w4Rd3n

w4Rd3n

    Advanced Member

  • Members
  • PipPipPip
  • 122 posts
  • Country: flag of Switzerland Switzerland


Posted 28 January 2012 - 12:12 AM

What range do you need? I use a class 1 module together with a class 1 BT stick and stopped the range test at about 600m :).

Wow. that is far enough. exactly what i am looking for. where can i get this ? :rolleyes: i ever thought BT is good for ranges up to 10m.

- Automatic "offline" tuning (evaluating flight logs in GCS and compute PID parameters to match some simple, adjustable parameters like response time or overshoot)
- Adaptive control loops (running on the flight controler and constantly adapts the PID parameters)


i really like how adaptive control works. The paparazzi project has tested this on planes and multirotors.
http://paparazzi.enac.fr

Corvus is working on it, James also had it planned. It will get done I think as it is needed.

this is great!

Edited by w4Rd3n, 28 January 2012 - 12:14 AM.


#13 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1912 posts
  • Country: flag of Germany Germany


Posted 28 January 2012 - 10:56 AM

Wow. that is far enough. exactly what i am looking for. where can i get this ? :rolleyes: i ever thought BT is good for ranges up to 10m.


There are two classes of bluetooth devices (Edit: three actually, but I never ran across a Class 3 device). Class 2 devices have a specified range of 10m while class 1 devices have higher output power and sensitivity and a range of 100m. Everything you normaly see in mobile phones, laptops etc. is a class 2 device but if you are looking for BT USB sticks, you'll see both, class 1 and class 2 devices. The setup I use is described here. Depending on the devices you'll probably not get the same range as I did but 100m in free air should not be a problem as this is what the specs are. There are modules out there that even claim to go over 1000m.
The only drawback I see is the potential problem with 2.4Ghz remote controls. A high power BT transmitter in close proximity to a 2.4Ghz RC receiver should cause a lot of trouble. I never tested this because I only have a 35Mhz RC but I it's hard to imagine that this has no impact.



I tried that, lost that one as well, I'll add you to the PM if you wish and want to help with the GUI? Reddog and Mike wanted percent, I wanted a number 1 to 20, maybe 1 to 15 is better and in normal language multiple the existing by 1000. Worse with the percent is if we change the ranges in a firmware revision, the meaning of the percent changes and all the past settings we have posted on the wiki become worthless, but by scaling up, it still makes sense.


Scaling it up by 1000 (for the GUI only, not in the firmware) is probably the only solution that makes sense to me and doesn't limit anything. Additionally, the positions after the decimal point could be limited to 2-3. I don't see how a simple integer value between 1-20 can be accurate enough for all kind of airframes and sizes..

Edited by D-Lite, 29 January 2012 - 09:35 AM.


#14 Caustic

Caustic

    Too many ideas and too little thoughts

  • Members
  • PipPipPip
  • 1943 posts
  • LocationDuncan/Victoria, BC
  • Country: flag of Canada Canada


Posted 28 January 2012 - 11:11 PM

Just a quick interjection, you are quoting specifications required for certification, not capabilities. It seems you may be limiting yourself by approaching it in this way.

Data throughput and range is far greater than the baseline profiles and class specifications. Unless you are planning to get certified or sell your device as a certified BT device (most likely not), why restrict what is available to you?
I swear that I try not to be, but I will eventually come across the same as my name! Just let me know.

Dankers note: This is not really true, this guy is nice, friendly and helpful. Sometimes he can give the impression he is a bit forceful but he doesn't mean to be. Top bloke.

#15 Guest_dankers_*

Guest_dankers_*
  • Guests

Posted 28 January 2012 - 11:13 PM

Scaling it up by 1000 (for the GUI only, not in the firmware) is probably the only solution that makes sense to me and doesn't limit anything. Additionally, the positions after the decimal point could be limited to 2-3. I don't see how a simple integer value between 1-20 can be accurate enough for all kind of airframes and sizes..


One decimal place should be enough really. On the advanced screen you can go nuts with the floats.

#16 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1912 posts
  • Country: flag of Germany Germany


Posted 29 January 2012 - 08:02 AM

Just a quick interjection, you are quoting specifications required for certification, not capabilities. It seems you may be limiting yourself by approaching it in this way.


It wasn't meant as a limit or an approach, just as a rule of thumb what range can be expected. If the Class 1 specification talks about 100m range, then it's safe to assume that any Class 1 device should be okay for that range (more or less). I reached 600m with my setup but this doesn't mean that this works for everyone.


Unless you are planning to get certified or sell your device as a certified BT device (most likely not), why restrict what is available to you?


Well, I'm not building a BT device :-). The BT-USB stick for the ground station is from a next door supermarket and and the flight side is a standard BTM-222 module, so all this components are certified already. The only thing that has further influence on range is the antenna I attached to the BTM-222. Apart from that - using devices that are not certified or modifying them to exceed limits like transmit power is certainly illegal in most countries, even if you don't sell the device.

#17 Caustic

Caustic

    Too many ideas and too little thoughts

  • Members
  • PipPipPip
  • 1943 posts
  • LocationDuncan/Victoria, BC
  • Country: flag of Canada Canada


Posted 29 January 2012 - 06:52 PM

As it stands, BT has a capability range in the area of 14km LOS with a focused antenna if I recall correctly. The DEFCON shootout results reveal why the specification range is not reality and how "stars" lose their information on unmodified, standard devices. Certified ranges are based on the antenna max power level at a specified range, not the capabilities of the hardware, as your experience shows.

The main class differences are in data throughput capabilities (not standard profiles). If I recall class 1 is ~700kb/s, class 2 is ~2Mb/s and class 3 is ~5Mb/s.

As a note: mainly my current BT work is around using the full data capabilities (which the standard profiles do not approach), not range factors, in fact my interest is within Bluetooth-LE. I just hate to see people accept the general published standards as they rarely match actual capabilities and specifications.
I swear that I try not to be, but I will eventually come across the same as my name! Just let me know.

Dankers note: This is not really true, this guy is nice, friendly and helpful. Sometimes he can give the impression he is a bit forceful but he doesn't mean to be. Top bloke.

#18 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1912 posts
  • Country: flag of Germany Germany


Posted 29 January 2012 - 08:12 PM

As it stands, BT has a capability range in the area of 14km LOS with a focused antenna if I recall correctly.


That's quite impressive but focused antennas are not very useful if one side of the connection is on an airframe. And I assume this result is with focused antenna plus running the transmitter at full power which is illegal (at least in germany). If the output power of the device is 20dbm and you add a 5db antenna, you would have to reduce the transmitter power by 5dbm.


The main class differences are in data throughput capabilities (not standard profiles). If I recall class 1 is ~700kb/s, class 2 is ~2Mb/s and class 3 is ~5Mb/s.


I think you are referring to BT versions here, not classes. The classes talk about maximum allowed output power:

Class 3: 1mW
Class 2: 2.5mW
Class 1: 100mW

The versions range from 1.0 to (currently) 4.0 and specify different data rates and features.


I just hate to see people accept the general published standards as they rarely match actual capabilities and specifications.


Yes, BT is a very complex an capable protocol and can do much more than it looks at a first glance.

#19 Caustic

Caustic

    Too many ideas and too little thoughts

  • Members
  • PipPipPip
  • 1943 posts
  • LocationDuncan/Victoria, BC
  • Country: flag of Canada Canada


Posted 30 January 2012 - 12:31 AM

That was 14km to intercept and decode a message from standard cell phone.

That is a bit off topic though, more on topic is why you are not using a freespace optical link with LEDs? Weather conditions if it starts to rain can be problematic but it can handle up to 75% signal degradation before failing. Range is somewhere between 2-5km.

Or maybe a low frequency long range rf?
I swear that I try not to be, but I will eventually come across the same as my name! Just let me know.

Dankers note: This is not really true, this guy is nice, friendly and helpful. Sometimes he can give the impression he is a bit forceful but he doesn't mean to be. Top bloke.

#20 mk1spitfire

mk1spitfire

    Advanced Member

  • Members
  • PipPipPip
  • 310 posts
  • Country: flag of United Kingdom United Kingdom


Posted 05 February 2012 - 04:52 PM

Dadocorp is working on this to convert to sliders. :D



Great
Open Pilot - 'Revolution'