• nope

    I was thinking about it last night, and I did in fact miss the other two axis' contributions to the third axis, which would explain why my script showed zero movement if I rotated the device by 90 degrees and moved in the original direction. I will be correcting that soon.
    Attitude does drift by a huge amount right after you start updating, and the lack of a magnetometer on the ipod touch makes using the third sensor impossible.

    posted in Pythonista read more
  • nope

    I was working on an dead reckoning script, despite hearing from just about everybody that the phone had too much noise/too low a frequency for sampling (Which turned out to be true, on my ipod touch 5th generation it drifts around 40cm per 5 seconds).
    Code here

    With the preset time constants, it should run on an iphone 4s/ ipod touch 5 directly. Each while loop takes approximately 0.08 seconds (you need 0.01 seconds to even start thinking about seeing the results real time). And to that end, I avoided using arrays/map/for loops/numpy.cos because my timing showed that it was slower than just setting var1=something, and using math.cos. Despite my best efforts, it cannot present accurate results. If people could check it for errors, that would be fabulous, and maybe a solution using pickle, and later analysis would work. Coded mostly in pycharm on the desktop.

    The numbers it returns is relative to your initial position according to this page(not the phones, assuming you are facing towards the short side of the phone)

    Interesting observations:
    Angle drift depended on how long the update has started, the longer, the less drift, that's why update is started and we wait 10 seconds.

    Acceleration drift is dependent on phone position, that's why you need to "calibrate it".

    Array creation is not worth it, if you're just using three numbers, also don't bother with numpy.
    alt text

    posted in Pythonista read more
  • nope

    I was using the equivalent of an direction cosine matrix, where the actual x vector would have to be "projected" on the plane global x, global y are on, then projected onto the x axis itself. Where cos(theta1)|x2|=|x1|, cos(theta2)|x1|=|x|. Please correct me if I made a mistake.

    The motion module returns <roll, pitch, yaw>. roll is around the y axis, pitch is around the x axis, and yaw is around the z axis. That means, roll does not affect y, pitch does not affect x, and yaw does not affect z. Assume that the gyro/accelerometer are in the center of the device, and the phone is flat on a table. We rotate the phone counter clockwise around the z axis for 1 pi. And move the phone forwards at constant acceleration m, if we want to get the motion relative to the original phone, we would need an value that is the negative of the original acceleration m, and the negative of the original speed, because we are moving away from the direction the accelerometer is telling us, at an increased speed(instead of decreasing as it's telling us). Only cos is an even function that would return cos(pi)= -1. Now imagine that in addition to that, we flip the phone over, front over end. That would cause the top side to be pointing towards the top again, a rotation of pi, (cos(pi))^2= (-1)^2=1, returning the correct vector again.

    The problem with attitude is the large amount of drift initially, after starting updates, it can drift by nearly 10 degrees, which makes it necessary to zero before using in each loop, which is marginally more difficult to compensate and slower to call than just using the cumsum of the rotation_rate.

    I share your concern with timing, but actually with a little bit of tweaking, I have gotten the error down to 1.2cm of drift per second for the first ten seconds for the x and y axis. The z axis is unusable due to the huge amount of noise still present.

    posted in Pythonista read more
  • nope

    Additional benchmarking showed that the print statement was taking up 98.5% of the 0.01 seconds, so delete that, and you can easily reach 100Hz, that reduces the noise so that you only have about 20m of drift in each direction every 10 seconds, an significant improvement. That means that we might be able to start doing some really fancy filtering on the data in real time to reduce the noise.

    posted in Pythonista read more
  • nope

    I thought it might be interesting to benchmark everything in my home that ran python, and compare the different speeds. I used the pystone benchmark that can be found here

    Here are my results:

    Ipod touch 5 with A5 processor at 800MHz Pythonista 1.4:
    50000 passes: 10.766 seconds, 4670.01 pystones/second
    ====================================================
    Edit:
    Ipod touch 5 with A5 processor at 800MHz Pythonista 1.5:
    10413.3 pystones/second for 50000 passes
    ====================================================
    Laptop with 2.3 GHz Core2Duo running windows 7 Python 2.7.5:
    50000 passes: 0.858592 seconds, 58234.9 pystones/second
    ====================================================
    Rasberrypi 700 MHz Ubuntu:
    50000 passes: 17.384 seconds, 2876.2 pystones/second
    ====================================================
    Desktop with stock intel 920 at 2.66 GHz win 7 Python 2.7.5:
    50000 passes: 0.67801 seconds, 73745.2 pystones/second
    ====================================================

    posted in Pythonista read more
  • nope

    Quite cool, how efficient is it?

    posted in Pythonista read more
  • nope

    I was just playing around with the ipod touch 5 accelerometer using pythonista's motion module. I wrote this little script to see how much the error was:
    http://pastebin.com/fr7tuuKJ
    Apparently the error is highly dependent on the position the phone is in (which side it's resting on). Can anybody else confirm this? That said, can omz comment on the frequency of the updates possible?

    posted in Pythonista read more
  • nope

    Ah, sorry about that, I just started it when python started and didn't add it into each individual script because it stayed started. But that aside, after you add the motion.start_updates() can you guys see any pos dependent error?

    posted in Pythonista read more
  • nope

    Pythonista 1.5, I'm getting 10413.3 pystones/second on the ipod touch 5th generation. There's a 100% jump from pythonista 1.4 to 1.5, that's impressive!

    posted in Pythonista read more
  • nope

    That's not right... The 4s has the same processor as the ipod 5. Keep in mind I'm running pythonista 1.4.
    Seems like they made quite an improvement from 1.4 to 1.5.
    Could people please list the pythonista versions/ python versions they are using?

    posted in Pythonista read more

Internal error.

Oops! Looks like something went wrong!