**** BEGIN LOGGING AT Thu Mar 06 18:02:19 2014 Mar 06 18:02:28 put that on the arm Mar 06 18:02:41 ok Mar 06 18:02:42 you need to understand the limitations of the PRU Mar 06 18:03:11 also, please clarify which PWM generator are you using on the PRU (same with the other stuff) Mar 06 18:03:44 I think you are aware of the 20 channel PRU PWM stuff I did, right? Mar 06 18:03:54 yes Mar 06 18:04:22 it is accurate to about a couple of us high/low Mar 06 18:04:54 how many PWM do you need? Mar 06 18:04:56 isn't there a eCAP thing on the PRU for PWM too? Mar 06 18:05:02 yes Mar 06 18:05:04 then there is the UART Mar 06 18:05:15 I don't know if those are pined out Mar 06 18:05:26 is this the 16550 compatible hw uart in the PRU? the one outside of it? or a software uart? Mar 06 18:05:34 panto: I thought it was a pinmux option? Mar 06 18:05:39 ds2, it a hardware uart Mar 06 18:05:42 *is Mar 06 18:05:50 ds2, not all pinmux options are possible Mar 06 18:05:57 the connectors are very limiting **** ENDING LOGGING AT Thu Mar 06 18:06:04 2014 **** BEGIN LOGGING AT Thu Mar 06 18:08:20 2014 Mar 06 18:08:26 and access it in a very simple and efficient matter from the PRU Mar 06 18:08:40 you might have to modify the kernel to do that Mar 06 18:09:14 if that document is to be used or part of the GSoC app... I would like to see a demostration of an understanding of why some things belong in the PRU and not on the ARM Mar 06 18:09:31 just so we don't waste the first half of GSoC sorting out what goes w/which block Mar 06 18:10:18 make a detailed list of what peripherals you have to use Mar 06 18:10:37 and then write a short paragraph about how you're going to use it Mar 06 18:11:04 ds2: Andrew Tridgel had conducted a very nice talk on the topic http://www.youtube.com/watch?v=ealH3qP_pBE Mar 06 18:11:09 a brief justification of why it should be used that way would be good Mar 06 18:11:30 sidbh: I don't have time to watch a video right now (got something coming up in a few minutes) Mar 06 18:13:14 sidbh: ok then skim through this http://uav.tridgell.net/LCA2014/AP_Linux.pdf Mar 06 18:13:32 got to step out for a while Mar 06 18:13:33 l8rs Mar 06 18:15:51 ds2:ok then skim through this http://uav.tridgell.net/LCA2014/AP_Linux.pdf Mar 06 18:16:17 doing it Mar 06 18:18:25 the 1mS time frame for gyros can be hard with the current code Mar 06 18:18:31 gyros/accel Mar 06 18:19:00 ds2:which current code? Mar 06 18:19:05 current kernel code Mar 06 18:19:29 yes, that's why we are leaning towards PRU Mar 06 18:19:58 the PRU won't help that much Mar 06 18:20:46 IIRC... I had sensors running as high as about 200-300Hz in the kernel Mar 06 18:20:56 but I think the timing is allover the place, IIRC Mar 06 18:21:10 I need to go Mar 06 18:21:24 ok Mar 06 18:41:00 vmayoral: check these converstion out, very interesting Mar 06 18:41:46 http://pastebin.com/FWDRtKM2-beagle Mar 06 18:41:46 http://pastebin.com/Fuuftdi2-beaglepilot Mar 06 18:44:43 Pastebim removed Mar 06 18:44:49 Again plz Mar 06 18:44:56 Both Mar 06 18:46:20 http://pastebin.com/FWDRtKM2 Mar 06 18:47:01 http://pastebin.com/Fuuftdi2 Mar 06 18:58:52 vmayoral: have you received pastebin links Mar 06 19:00:39 going through them now Mar 06 19:00:45 ok Mar 06 19:03:56 does anyone know where the nslu2-log(s) are posted? Mar 06 19:04:32 who has setup nslu2-log Mar 06 19:04:34 ? Mar 06 19:06:11 found them... but forbidden access http://logs.nslu2-linux.org/livelogs/beaglepilot.txt Mar 06 19:21:59 vmayoral: any thoughts on the discussions with ds2 and panto? Mar 06 19:54:40 sidbh: sorry i didn't answer before Mar 06 19:54:46 checked the conversations Mar 06 19:54:55 good ones, well done! Mar 06 19:55:43 panto, ds2: are you guys willing to mentor the project? we'd be happy to have you Mar 06 19:55:49 vmayoral: I guess we will need huge help from mentors like ds2 and mdp Mar 06 19:56:12 as I said on #beagle, sure as long as I'm having some help from ds2 and mdp :) Mar 06 19:57:01 panto: so are you onboard :) Mar 06 19:57:41 great! Mar 06 19:57:43 :) Mar 06 19:57:45 I will need to be bribed with a device to *cough*test*cough* Mar 06 19:57:57 i saw that somebody mentioned that the ADCs are not accessible from the PRU Mar 06 19:58:18 not directly Mar 06 19:58:29 they could be made to work, but it will be a hassle Mar 06 19:58:39 guess i'll have to do it in ARM then Mar 06 19:58:54 if you use it just for battery that's a good idea Mar 06 19:59:20 yes, that's the main idea Mar 06 19:59:45 vmayoral|work, you're from .it? Mar 06 20:00:05 i'm spanish but i work in Italy Mar 06 20:00:27 so we're quite close ;) Mar 06 20:00:36 where are you based? I'll due for some travel near Turin Mar 06 20:00:41 *I'm Mar 06 20:01:04 My research center is located in Pontedera, near Pisa Mar 06 20:01:25 you're a little bit far Mar 06 20:01:57 yeap :(, you're going to the cold part of Italy Mar 06 20:02:06 tell me about it :( Mar 06 20:02:09 and rainy Mar 06 20:02:15 Although i've heard it's quite nice over there for entrepreneurs Mar 06 20:02:26 I'm a working stiff Mar 06 20:04:03 panto: you don't have BBB with you? Mar 06 20:04:12 I do, but I don't have the flying part Mar 06 20:04:15 samy_: jkridner informed me that you have not registered yourself in melange as a mentor for this project, did you solved it? Mar 06 20:04:37 you are going to make it fly, won't you? Mar 06 20:04:54 yeah, that's the target Mar 06 20:05:02 panto, sidbh: that's the idea :). Although it's going to be a lot of work. We can all agree on some hardware Mar 06 20:05:11 basically motors, ESCs and battery Mar 06 20:05:20 but tridge suggested that we should start with a rover Mar 06 20:05:33 as long as we're not hand-waving Mar 06 20:07:36 sidbh: i'm going to try the PRUSS-C library now Mar 06 20:07:45 cool Mar 06 20:19:53 vmayoral: I guess we have to discuss about arranging hardware for some of our mentors, maybe our existing mentors with contacts in DIY drone industries might help regarding this issue Mar 06 20:20:16 sidbh: looks like you missed something, got a similar error as yesterday Mar 06 20:20:20 https://gist.github.com/vmayoral/9398788 Mar 06 20:20:44 sidbh, I'm asking for a real device, cause I don't have any illusions about getting anything to work without it Mar 06 20:21:04 if you spend time dicking around without a device you'll get nowhere fast Mar 06 20:21:41 panto: yeah that is true Mar 06 20:22:13 vmayoral: i guess there is a problem of export command Mar 06 20:22:23 which command did you used Mar 06 20:22:29 well i found something but that's not causing the problem Mar 06 20:22:42 in the README you have: export PRU_C_DIR="/path/to/ARMLinuxA8/include;/path/to/ARMLinuxA8/lib" Mar 06 20:22:55 vmayoral: nope Mar 06 20:23:06 sorry Mar 06 20:23:08 that's my line Mar 06 20:23:25 no I actually pasted it fine Mar 06 20:23:38 that's written at "for arm systems" Mar 06 20:23:47 vmayoral: refer section Compiling with starterware Mar 06 20:23:58 yes yes, aware of that Mar 06 20:24:04 just pointing out another typo Mar 06 20:24:11 the ";" should be replaced by ":" Mar 06 20:24:20 let me know if you don't see it and i'll modify it Mar 06 20:24:51 followed exactly "Compiling PRU source code with StarterWare driver library" and got the problems i pasted in the gist Mar 06 20:25:08 no for PRU_C_DIR it is ; Mar 06 20:25:20 i have checked it Mar 06 20:25:27 ok Mar 06 20:25:32 apologies, my mistake then Mar 06 20:25:49 no clue what's going on then Mar 06 20:25:55 anyways you don't need to export PRU_C_DIR Mar 06 20:27:44 i thought it might be need since the error mentions PRU_C_DIR Mar 06 20:28:26 no it isn't you need to export PRU_BASE_PATH correctly Mar 06 20:28:41 everything else is taken care of by make Mar 06 20:29:17 panto: regarding hardware, i'd love to be able to provide boards of Erle but i can't assure anything because we're really small and super low on cash. But if we get a BBB and a PixHawk Fire Cape the rest should be straightforward (at least for quadcopters which is what i know about) Mar 06 20:29:33 cool Mar 06 20:30:06 and i'm confident that BBB+PixHawk should be quite sure Mar 06 20:30:41 Craig from 3D Robotics promised me one and he's following the project i believe so it shouldn't be a problem shipping a couple more Mar 06 20:31:08 ok, time to go now Mar 06 20:31:10 g'night all Mar 06 20:31:19 good night Mar 06 20:31:19 good night Mar 06 20:33:33 vmayoral: any developments? Mar 06 20:33:38 yeap Mar 06 20:33:40 my mistake Mar 06 20:33:44 everything's fine now Mar 06 20:33:59 cool Mar 06 20:34:11 let me run it Mar 06 20:36:36 mmm thought executing blinkled.out would work but nop Mar 06 20:36:51 seems it's not a binary Mar 06 20:37:42 no you have to copy text.bin and data.bin to the blinkled folder in the previous example Mar 06 20:38:16 i'm yet to develop the app for uploading the binaries Mar 06 20:38:55 so for now using ones from pru-pasm Mar 06 20:39:03 project Mar 06 20:39:38 ok Mar 06 20:39:52 this sunday i'll make the whole project cleaner and user friendly Mar 06 20:40:33 :) Mar 06 20:40:38 tridge: ping Mar 06 20:40:52 good morning victor Mar 06 20:40:57 tridge: good morning! Mar 06 20:41:25 tridge: i updated a bit the "Real Time integration/evaluation: " part within the third workpack, i wanted to ask you a couple of things Mar 06 20:41:54 i'm finishing a userspace python implementation of a (super) simple autopilot https://github.com/erlerobot/erle_control Mar 06 20:41:55 sure Mar 06 20:42:10 there're some videos available in the proposal that show that the performance is not good (expected) Mar 06 20:43:08 then my idea is to quickly port the Xenomai implementation of the LinuxDrone guys to Erle (a quad that i have) finishing on ArduPilot full time Mar 06 20:43:12 yep, writing a autopilot with good performance isn't easy :) Mar 06 20:43:42 my with this steps is to acquire a better understanding of the performance of different systems to benefit ardupilot as much as possible Mar 06 20:43:48 what do you think? Mar 06 20:43:58 i plan doing this in the following 2-3 weeks Mar 06 20:43:58 i'd certainly be interested in seeing some comparitive results of scheduling and SPI/I2C performance with Linux+RT vs Xenomai Mar 06 20:45:27 the tests I did previously with 3.8.13+RT-PREEMPT showed that the basic kernel performance is good enough for what we need. The weak point is sensor access. Mar 06 20:47:13 (back in 5 mins) Mar 06 20:47:20 sure Mar 06 20:55:54 thanks for the updated doc! a few comments Mar 06 20:57:22 first off, I don't think you should concentrate on the EKF. A good EKF is a non-trivial project, plus we already have one in APM. It also misses the point I think - we don't want to hide poor sensors using high level filters. We just want to have great sensors in the first place. If we feed the ardupilot code good sensor data then it flies extremely well, as demonstrated by APM2, PX4, Pixhawk, Flymaple etc ports Mar 06 20:57:49 a good sensor driver has the following testable properties: Mar 06 20:58:33 1) very consistent timing. If we ask for 1kHz sampling from a SPI gyro then it should give us 1kHz samples, with the amount of variation in timing very small. Mar 06 20:59:33 2) low CPU impack. We should be able to run 6 SPI devices each doing 1kHz sampling on multiple SPI buses without more than about 20% CPU load Mar 06 20:59:46 s/impack/impact/ Mar 06 21:00:28 3) consistent timing even when under load. We should be able to put significant CPU and IO load on the BBB while running the sensor test and not degrade the sensor performance Mar 06 21:00:58 i see Mar 06 21:01:04 note that we can use the FIFOs on the sensors to reduce interrupt cost and CPU load Mar 06 21:02:31 the way I did my testing so far was to run C code to capture sensor data from I2C and SPI devices and used clock_gettime(CLOCK_MONOTONIC,) to measure the timing consistency of the sensor capture Mar 06 21:02:48 I also watched the transfers using a logic analyser to confirm the timing Mar 06 21:04:06 we still have to work out the exact design we should use for SPI/I2C access, but I suspect the best result will be to have one RT thread per bus (so if 2 SPI buses then two threads) Mar 06 21:04:25 tridge: i'd like to follow your advice. I guess i shouldn't try the LinuxDrone way but focus directly on the tasks required by ArduPilot. Mar 06 21:04:28 each thread would have a shared memory ring buffer of bus transfer requests from drivers Mar 06 21:04:54 speaking about threads on the APM code Mar 06 21:04:56 I've been reading the code and annotating it before going to sleep for the last two weeks and there's something that still i don't quite understand about the AP_HAL_Linux. Where in the code do you set the thread priorities so that they are not preempted by other not so relevant tasks running in the processor? Mar 06 21:05:30 vmayoral|work: well, I would be interested in comparing the results with Xenomai, it may be a better approach than RT-PREEMPT, I just don't know Mar 06 21:06:05 the thread priorities are set in Scheduler.cpp - see this block of defines: Mar 06 21:06:10 #define APM_LINUX_TIMER_PRIORITY 13 Mar 06 21:06:10 #define APM_LINUX_UART_PRIORITY 12 Mar 06 21:06:10 #define APM_LINUX_MAIN_PRIORITY 11 Mar 06 21:06:10 #define APM_LINUX_IO_PRIORITY 10 Mar 06 21:06:26 noted, thanks Mar 06 21:06:48 currently all sensor reads are done by a single timer thread. I don't think that is a good method, but it worked for initial testing Mar 06 21:07:03 as I mentioned above, I think we'll probably end up with a thread per bus Mar 06 21:07:14 or possibly a kernel thread per bus Mar 06 21:07:44 then individual sensor drives (eg. gyro driver) would put bus read requests and callback functions in a ring buffer Mar 06 21:08:24 do we have kernel drivers for all the sensors? Mar 06 21:08:27 the bus-thread would be sleeping on timer wakeups and also be woken by insertion into the ring buffer Mar 06 21:08:38 is saw that Philip included a MPU-9250 Mar 06 21:08:39 no, we don't have kernel drivers for any of the sensors :-) Mar 06 21:08:48 i have not found a kernel driver for that one Mar 06 21:08:49 writing a sensor driver isn't hard though Mar 06 21:09:00 probably the userspace one can be taken as a starting point Mar 06 21:09:08 i have some experience with that one Mar 06 21:09:20 the trick is working out what model we will use for data transfer, bus wait etc Mar 06 21:10:38 i think we should do all userspace drivers initially, using the kernels SPI API. Mar 06 21:10:55 the initial aim will be to prove all of the hw on the cape works, or identify which bits don't work Mar 06 21:11:20 the reason that is a priority is that only a couple of boards will be hand-populated with parts initially Mar 06 21:11:34 then once we prove the hw works they can go to machine production Mar 06 21:11:36 * vmayoral|work is writing the timeline as tridge speaks :) Mar 06 21:11:57 we should follow these steps for sure Mar 06 21:12:00 so we're not aiming for efficiency with the initial code - just proof that every bit of hw responds Mar 06 21:12:01 we can use userspace-arduino project for userspace testing Mar 06 21:12:25 sidbh: we can just do it in ardupilot - adding a simple driver in APM code is easy Mar 06 21:12:54 ardupilot is already running on the BBB and can already use some sensors (the cheap 10dof ebay boards I tested with) Mar 06 21:13:14 so its easiest to just make a new simple driver for each sensor Mar 06 21:13:29 we can start working on that, yeap Mar 06 21:13:34 the driver doesn't need to be optimal, it just needs to prove that we can get the data Mar 06 21:14:28 tridge: quick question, do you recommend us to set up a SITL setup? Mar 06 21:14:41 Kevin mentioned it i believe Mar 06 21:15:06 SITL is well worth learning, yes, and is easy to setup. See the wiki page here: http://dev.ardupilot.com/wiki/setting-up-sitl-on-linux/ Mar 06 21:15:12 tridge: sorry if I missed something, but, if you use sensors different from the ones used on the px4 boards, won't you have to model them to work with the ekf code which you plan to the one from apm? Mar 06 21:15:28 *which you plan to use from apm Mar 06 21:15:43 SITL in some ways is the grandfather of the BBB port of ardupilot. Doing SITL required that APM was ported to 32 and 64 bit CPUs Mar 06 21:16:20 hatguy: using a new sensor is really easy, plus the sensors on the fire cape are very similar to the pixhawk sensors. Mar 06 21:16:33 tridge: ahh makes sense Mar 06 21:16:58 hatguy: the sensor driver is told what aa-filter bandwidth is needed, it just needs to pick the closest compatible filter bandwidth and provide the samples Mar 06 21:17:04 the APM code takes care of the rest Mar 06 21:17:25 perhaps I should explain the filter strategy APM uses? Mar 06 21:17:35 tridge: all right then, i will dedicate some time to set up SITL Mar 06 21:17:35 that would be awesome :) Mar 06 21:17:41 +1 Mar 06 21:17:53 +1 Mar 06 21:17:54 ok, would you like it in text here, or shall we do a G+ hangout with screen sharing? Mar 06 21:18:29 anyway you like Mar 06 21:18:31 i'm fine with both Mar 06 21:18:51 if you all have audio (mic, speakers) then a G+ hangout would be fun to meet you all Mar 06 21:19:14 i'm Andrew Tridgell on G+, add me to your circles so I can find you all Mar 06 21:19:22 sure, but my accent might be a bit hard to understand :) Mar 06 21:19:32 would you prefer text? Mar 06 21:19:40 I can just type if you like :) Mar 06 21:19:57 I'll start typing and see how we go .... Mar 06 21:20:04 if it's possible right now.. it is a bit late here Mar 06 21:20:15 ok, lets consider gyros and accels first Mar 06 21:20:16 yeah, everyones sleeping at my home, don't want to wake them up Mar 06 21:20:40 go ahead.. Mar 06 21:21:11 the aim of the gyro and accel drivers is to get accurate accelerometer and gyro readings with predictible latencies, resiliance to vibration and high sample rate Mar 06 21:21:33 to fly an aircraft you don't need a lot of sensor bandwidth - typically we filter to between 20 and 40Hz bandwidth Mar 06 21:21:51 but to get vibration resiliance you need to sample at a _much_ higher rate Mar 06 21:21:56 so what we do is this: Mar 06 21:22:52 1) configure the sensors analog anti-aliasing filter with an appropriate bandwidth. This is usually 30 to 50Hz, and is calculated by Leonard Hall, our filter guru, to give the right balance between latency and noise rejection Mar 06 21:23:50 2) sample the gyros and accels at the highest rate we can do on the hw within the CPU and bus constraints. On APM2 that is 200Hz. On Pixhawk it is 1kHz for MPU6k and 800Hz for the LSM303D and L3GD20 Mar 06 21:24:26 3) put the samples we get from the sensors through a 2-pole butterworth filter tuned to the sensor bandwidth we want (typically 20 to 40Hz depending on the vehicle type) Mar 06 21:24:44 sorry - why lower for the backup mpu6050? Mar 06 21:24:58 I mean *higher Mar 06 21:25:14 4) the output of the butterworth filter is what the INS drivers in libraries/AP_InertialSensor gives Mar 06 21:25:29 (yep, I'll answer Qs in a sec ... just completing basic flow control) Mar 06 21:26:10 sorry - go ahead Mar 06 21:26:42 5) the output of the INS driver goes into the higher level attitude and position filters, right now in APM that is fed in parallel into our DCM and EKF filters. On APM2 we only use DCM as EKF is too expensive. On Pixhawk/PX4 we use both in paralllel, giving us two sets of AHRS results. The user can switch between these two high level filters in flight Mar 06 21:27:44 6) on top of all this we have multi-sensor intergation. For example, the EKF can learn the correct relative weights of dual-accelerometer setups, and DCM can choose the right accelerometer to use based on consistency of each sample with the current attitude solution, corrected for inertial movement using GPS velocities Mar 06 21:28:37 ok, that gives you a rough idea of how things flow through the code. All that is missing on BBB is the low level drivers to get the samples from the sensors. All the rest of the code is tested production code that is flown by thousands of people already Mar 06 21:29:13 that's a really valuable explanation tridge, thanks a lot, really! Mar 06 21:29:41 hatguy: ok, Q on the different sample speeds. The reason for the difference is just what the chip can do. Sensors like these can't do arbitrary sample rates. You set bits in config registers to tell the chip "I want this combination of bandwidth and sample rate" Mar 06 21:29:44 absolutely! much more than what I would get from reading tons of code :) Mar 06 21:30:06 it is a discrete table, and MPU6K can do 1kHz, the STM parts (LSM303D and L3GD20) can do 800Hz Mar 06 21:30:33 that is actually a good thing - when we have multiple sensors of the same type we benefit hugely from having different sample rates Mar 06 21:30:46 that is due to aliasing effects. Do you guys know about aliasing? Mar 06 21:31:05 maybe I should explain it anyway, stop me if it is boring Mar 06 21:31:10 a little... multiple images, right? Mar 06 21:32:09 imagine you are flying a plane and you have a propeller spinning at 15k RPM, which is around 250Hz for a 2 blade propeller Mar 06 21:32:14 i'd like to hear the explanation please Mar 06 21:32:39 that will give a major vibration at 250Hz. Now you will also get harmonics of that vibration, at 500Hz and 1kHz Mar 06 21:33:01 ok, so the propeller will be injecting substantial energy at 1kHz. Now imagine you are sampling at 1kHz Mar 06 21:33:23 you can think of the vibration as a sine wave at 1kHz, and you are sampling at 1kHz. Mar 06 21:33:42 so your samples can line up with the vibration. Imagine the vibration has an amplitude of 10m/s/s Mar 06 21:34:06 then the Z accelerometer will see a DC offset of 10m/s/s if the sampling lines up with the peaks of the noise Mar 06 21:34:35 but if you have a 2nd accelerometer sampled at 800Hz then it will see a shfiting pattern of noise, with an average value of zero Mar 06 21:34:59 so for that noise, the 2nd accel will give great results, but the first one will think you are in free fall, even when sitting on the ground! Mar 06 21:35:24 this happened to me 2 weeks ago in my bigstik nitro powered plane Mar 06 21:35:57 * hatguy wonders how you managed to find the reason! Mar 06 21:36:19 it was flying perfectly, then at a very particular throttle level the vibration frequency lined up with the 1kHz sampling of the MPU6k and the DCM (which was only using the one accel) suddenly got a 90 degree pitch error! Mar 06 21:36:33 the plane dived straight at the ground (I switched to manual and recovered) Mar 06 21:36:53 since then I changed DCM to use both accelerometers Mar 06 21:37:25 and the problem is gone. We have a "replay" system in APM that allows us to take raw sensor data from a flight and replay it through new code to see if it fixes a problem. It does Mar 06 21:37:38 hang on while i make some graphs of what happened with the BigStik Mar 06 21:38:17 awesome.. so we can do some kind of averaging/estimation using both instead of using one as a backup? Mar 06 21:38:25 * sidbh now understands the benefit of having multiple sensors Mar 06 21:38:43 yes, the git master code now uses both accels, both gyros and I'm currently working on dual-GPS support Mar 06 21:38:57 for the BBB we will have 3 accels and 3 gyros Mar 06 21:39:03 so we can do median selection Mar 06 21:39:09 correct me if I'm wrong but previously we had the mpu6050 as backup right? Mar 06 21:39:13 nice... Mar 06 21:39:32 * hatguy likes medians Mar 06 21:39:57 the mpu6000 (not 6050 actually, minor difference) is the primary sensor, the LSM303D/L3GD20 is the backup, though primary/backup is now a loose term as we use both all the time Mar 06 21:40:09 really it is instance=0 and instance=1 in the code Mar 06 21:40:21 instance=0 is the MPU6k on the Pixhawk Mar 06 21:40:39 on PXF cape we have yet to decide the instance ordering :) Mar 06 21:40:49 I see... Mar 06 21:41:25 i really need to teach you all to use mavgraph, mavflightview, replay, mavlogdump etc Mar 06 21:41:33 they are the core tools needed for APM analysis Mar 06 21:41:53 Are there any tutorial about those topics? Mar 06 21:42:06 maybe instead of me posting graph images I should post some command lines for how to run these on the logs for my BigStik ? Mar 06 21:42:10 tutorials* Mar 06 21:42:11 yepp ... I was trying to get them to work these couple of days... I still can't figure out how to send mav messages to the pixhawk using commandline Mar 06 21:43:01 tridge: that would be great! some mavproxy commands too to use with the pixhawk, if it's possible Mar 06 21:43:13 * sidbh is struggling with using mavlink to send commands to pixhawk Mar 06 21:43:33 mavgraph.py ~/project/UAV/BigStik/logs/2014-02-22/log15.bin IMU.AccZ IMU2.AccZ RCOU.Chan3:2 Mar 06 21:43:53 see logs here: http://uav.tridgell.net/BigStik/logs/2014-02-22/ Mar 06 21:44:31 the most interesting part of that graph is about 40% in, when I was testing the engine on the ground Mar 06 21:44:58 as I raised the throttle the Z accel of the MPU6k (IMU.AccZ) went from -10m/s/s to +1m/s/s Mar 06 21:45:05 so it had 11 m/s/s of aliasing Mar 06 21:45:37 (phone call) Mar 06 21:46:29 mavgraph.py ~/project/UAV/BigStik/logs/2014-02-22/log15.bin AHR2.Pitch RCOU.Chan3:2 Mar 06 21:46:44 cool... so how does anti aliasing help here? you can't really have filters for canceling out motor vibrations, can you? Mar 06 21:48:29 hatguy: yes, filters can remove the vibrations. It is ideal to do it with physical isolation that that is hard in many models. The aim of APM is to be able to fly well even if the aircraft is very badly setup. I usually hard-mount my autopilots on the airframe and deliberately try to maximise vibration, using unbalanced props and nitro/petrol engines. I then make sure APM flies perfectly despite the bad aircraft setup Mar 06 21:49:17 tridge: i believe there're still a lot of concepts i need to get familiar with. Fortunately got the time and desire so i can't wait to start. I will review these conversation to update a bit the proposal if it's fine for you. Mar 06 21:49:22 in the above graph you can see the pitch from DCM (AHR2.Pitch) going crazy while on the ground due to aliasing Mar 06 21:49:51 tridge: i will set up tomorrow SITL and try to play a bit with mavgraph, mavflightview, replay and mavlogdump Mar 06 21:50:03 the RCOU.Chan3 is the throttle btw, its a reversed throttle, so lower numbers are higher Mar 06 21:50:51 yepp I just ran it.. Mar 06 21:51:05 tridge: next, I'll dive into ArduPilot. I have with me Erle so until i get the PixHawk Fire Cape i will make some tests with it Mar 06 21:51:21 next I'll show you how to test the replay code, to show the fix Mar 06 21:51:24 tridge: i believe you mentioned that you used some of those 10DOF cheap sensors with APM in Linux, right? Mar 06 21:51:31 cd to Tools/Replay in ardupilot git Mar 06 21:51:34 and run this: Mar 06 21:52:11 make linux && /tmp/Replay.build/Replay.elf ~/project/UAV/BigStik/logs/2014-02-22/log16.bin Mar 06 21:52:41 don't have the ardupilot git atm... will do it tomorrow morning Mar 06 21:52:42 (note I use the Linux HAL port to do replay, as it has hooks for time control, allowing faster than realtime playback) Mar 06 21:52:53 after running that cmd run this: Mar 06 21:53:36 ./plotit.sh FLIGHT.Pitch DCM.Pitch EKF.Pitch3 Mar 06 21:53:42 (relies on gnuplot) Mar 06 21:54:05 that gives a graph showing how the current dual-accel code now correctly detects and removes the aliasing effects for that flight Mar 06 21:54:36 and shows that we up to around 80 degree pitch error during the flight Mar 06 21:54:53 both EKF and DCM filters now gives the right attitude (and agree with each other, which is nice) Mar 06 21:55:04 nice... Mar 06 21:55:22 (err, sorry, typo, its EKF.Pitch not EKF.Pitch3) Mar 06 21:56:38 tridge: thanks for the superb lesson.. will need a couple of hours to digest it all Mar 06 21:57:04 :) Mar 06 21:57:13 ok, do try the above commands, and play around with them. Also look at how the EKF responded to altitude in the flights Mar 06 21:57:34 sure... Mar 06 21:57:35 tridge: wonderful discussion, thankyou :) will try first thing in the morning Mar 06 21:57:41 same here Mar 06 21:57:49 great, enjoy! Mar 06 21:58:06 tridge: one last question if possible Mar 06 21:58:15 sure Mar 06 21:58:27 tridge: same here (a bit off-topic, though) Mar 06 21:59:27 tridge: will the pixhawk respond to SET_QUAD_SWARM_ROLL_PITCH_YAW_THRUST messages by default? Mar 06 21:59:52 I put this up on the drones-discuss list but I'm not sure if that's the right list to ask this question Mar 06 22:00:52 hatguy: rather than answering, I think I should teach you how to check for yourself. cd to the ardupilot git tree, and run "git grep -n QUAD_SWARM". You'll see the only hits you get are in the auto-generated libraries/GCS_MAVLink/include/mavlink code Mar 06 22:01:17 that means the XML compiler has generated the stubs for that message, but no code watches for it and takes any action Mar 06 22:01:20 tridge: this one is off-topic as well, i want to try to get the hardware i have with me, Erle (which uses one MPU9150) to run the APM. I believe this shouldn't be much trouble since it's already running everything necessary https://github.com/erlerobot/wiki/wiki/Installing-ArduPilot Mar 06 22:01:41 hatguy: so to add it you would need to add code in ArduCopter/GCS_MAVLink.pde Mar 06 22:01:55 tridge: yeah I tried that but not in the ardupilot git but in the nuttx tree.. that code is intense! Mar 06 22:01:56 tridge: i just need to understand properly how to wire the sensors and the pins correctly, any pointer on this matter? Mar 06 22:02:07 tridge: thanks, I'll try that out Mar 06 22:02:33 vmayoral|work: ok, this is on a BBB, yes? Mar 06 22:02:41 It's a BB Mar 06 22:02:44 BB-based Mar 06 22:03:00 no HDMI or MMC and serial miniUSB supported Mar 06 22:03:26 ok, great. You need SCK, MISO, MOSI, CS, GND and VCC connected to the BBB Mar 06 22:03:50 is MPU9150 a single chip select chip? or a chip select per function? Mar 06 22:03:59 and I assume its on SPI? Mar 06 22:04:05 (maybe its I2C?) Mar 06 22:04:06 no, it's on I2C Mar 06 22:04:30 ahh, ok, so on I2C its a bit simpler, but much slower :-) Mar 06 22:05:13 just SCL, SDA, GND and VCC Mar 06 22:05:28 have you identified those pins on your board? Mar 06 22:05:43 tridge: just gave you access to a Google Doc excel where we are writing the hardware map pins Mar 06 22:06:00 i though you were already in, my mistake Mar 06 22:06:30 https://lh5.googleusercontent.com/-gvZ6d9dPMiI/UlHql4abubI/AAAAAAAADm4/7QZPpKti7Uw/w801-h601-no/IMG_20131001_174545.jpg Mar 06 22:06:49 that is a photo of my BBB connected with both I2C and SPI to a sensor board Mar 06 22:07:29 tridge: i see, in my case the sensors and the BB are in the same substrate Mar 06 22:07:51 ok, so that saves some crazy wires :) Mar 06 22:08:06 i think the image in the main web illustrates it Mar 06 22:08:09 http://erlerobot.com/ Mar 06 22:08:18 does the sensor show up with i2cdetect? Mar 06 22:08:26 this one better http://erlerobot.com/blog/wp-content/uploads/2014/02/20140215_142453-1272x954.jpg Mar 06 22:09:43 ie. what does "i2cdetect -y -r 1" give? Mar 06 22:11:05 * tridge downloads MPU9150 datasheet Mar 06 22:12:30 vmayoral|work: you have designed with allegro before? Mar 06 22:12:41 * vmayoral|work is checking Mar 06 22:12:41 yeap, yeap, putting it into a gist Mar 06 22:12:41 https://gist.github.com/vmayoral/9400825 Mar 06 22:12:41 * vmayoral|work pities his house internet Mar 06 22:12:41 the 68 corresponds to the MPU9150 Mar 06 22:12:42 I'm basically reading from the DMP processed values Mar 06 22:12:43 the userspace driver gives either quaternions or euler angles Mar 06 22:12:43 i'm using directly those ones Mar 06 22:13:02 ahh, for APM you don't want to use DMP Mar 06 22:13:10 DMP is basically for mobile phones :) Mar 06 22:13:23 its useful for flying vehicles as it can't properly account for inertial forces Mar 06 22:13:25 hatguy: with allegro you mean Orcad PSpice? Mar 06 22:13:53 vmayoral|work: yeah the format in which the BBB hardware files are released Mar 06 22:14:14 s/useful/useless ! Mar 06 22:14:15 hatguy: yes, i spent a couple of months learning it from 0 Mar 06 22:14:41 vmayoral|work: that's amazing.. commendable work.. I assume it must have been a pain working with the BBB layout? Mar 06 22:15:03 tridge: then i guess i could use the raw gyros, magnetometers and accels? Mar 06 22:15:19 tridge: pass them to the APM? that's where i'm getting lost Mar 06 22:15:25 yes, thats what you need if you actually want to fly it Mar 06 22:15:56 tridge: yeah because using the DMP ... well the videos say it all, i even cut myself :( Mar 06 22:16:13 hatguy: thanks, it was a bit tough but i was really motivated Mar 06 22:16:18 vmayoral|work: you need to write a libraries/AP_InertialSensor/AP_InertialSensor_MPU9150.cpp driver Mar 06 22:16:44 also, a I2C accel/gyro will never fly well. It isn't fast enough, even at 400kHz Mar 06 22:17:16 you probably can get it to fly, but never as well as a good SPI sensor Mar 06 22:17:28 * hatguy now realizes the wisdom of using the mpu6000! Mar 06 22:17:39 and its cheaper too :) Mar 06 22:17:47 vmayoral|work: nice... you must see great potential in this :) Mar 06 22:17:59 tridge: ahh Mar 06 22:18:32 its easy to see why. Each 3 axis sensor needs to transfer at least 6 bytes per sample (2 bytes per axis). Usually actually takes 8 to 10 with various status words Mar 06 22:18:55 hatguy: yes, i do :). I really believe that APM is going to become for Robotics what Linux is nowadays for all of us Mar 06 22:19:10 hatguy: and i really envision robots flying around sooner than we expect :) Mar 06 22:19:14 if you want high rate sampling (say 800Hz or 1kHz) then that is around 8kByte/sec Mar 06 22:19:22