Jump to content


Full Members
  • Content count

  • Joined

  • Last visited

  • Days Won


jayjay23 last won the day on October 19 2015

jayjay23 had the most liked content!

Community Reputation

107 Excellent

About jayjay23

  • Rank
    Advanced Member

Profile Information

  • Location
    Germany, Landsberg am Lech
  1. Firmware

    Regarding the MPU it goes like this, the lib just read the register map (RM-MPU-6000A.pdf) starting from ACCE_XOUT_H, 14 bytes, this is all these values: ACCEL_XOUT_H ACCEL_XOUT_L ACCEL_YOUT_H ACCEL_YOUT_L ACCEL_ZOUT_H ACCEL_ZOUT_L TEMP_OUT_H TEMP_OUT_L GYRO_XOUT_H GYRO_XOUT_L GYRO_YOUT_H GYRO_YOUT_L GYRO_ZOUT_H GYRO_ZOUT_L So you get a 14 byte array as above. s16 mpuData[8]; MPU6050_GetRawAccelGyro(mpuData); // HINT we define here the board orientation (may subject to change/configure) int16_t upDownAccel = mpuData[0]; int16_t frontBackAccel = mpuData[1]; int16_t leftRightAccel = mpuData[2]; int16_t frontBackGyro = mpuData[4]; // just a guess int16_t leftRightGyro = mpuData[5]; This is the none DMA example. In init you set the scale of the values, the int16 is -16k to +16k and the scale defines what's the rang in physical units. So if you set the accel scale to 16G (MPU6050_ACCEL_FS_16) this means -16k is -16G (or half, not sure right now). So to get a physical unit G value you just need to divide properly. So the scale also defines the sensitivity, you could decide to go for a smaller scale to have more sensible values, meaning each integer step is a smaller - so more precise - physical step. The same applies for the gyro, physical unit is rad/s. From this point I just used some basic trigonometry (while I'm not 100% sure, whether I choose the correct observer point of view, as I don't know what the filters expect, but I guess they can work with any value, it's how we feed the result in the PID loop and it's our own decision how the filter/PID output is converter to rotation): // PI/2 - acos([frontBackAccel|leftRightAccel]/16383,5) float fwBkAccelAngle = PI/2.0 - acos(frontBackAccel/16383.5); float leftRightAccelAngle = PI/2.0 - acos(leftRightAccel/16383.5); // calculate gyro rate in rad/s float fwBkGyroRadS = frontBackGyro/5000; uint16_t loopTime = utilDelayCnt; *fwBkAngle = callFilter(fwBkOldAngle, fwBkAccelAngle, fwBkGyroRadS, loopTime); fwBkOldAngle = *fwBkAngle; Here the constant dividers (16k and 5k) are just plain wrong, they need to be carefully adjusted according to the scale choosen, bu this was actually the point were I left of due to float instability. I wanted to try that code tonight, but for some reason my programming adapter didn't wanted to connect. Anyway I hope above explanation makes looking through the spec shorter.
  2. Firmware

    @electric_vehicle_lover: This findings is really great, actually I thought that current control should be possible. Even I'm not really finished I put up back the wheel stuff to my desk and will try the math stuff next days, so far I was busy with this stuff (eib bus components for our house) and also had some time shortage due to child care special situation which hopefully clears next weeks: This week is so warm here in germany that I started to go by wheel again (I didn't wanted to try on ice, thoug vee has a really cool spikes mod :-))
  3. Firmware

    I read through that and it's a good explanation of what has to be done, I didn't digged into any code as the stuff needed is already at our hands and I would say to look at something new only if it just doesn't work in general. ok!! That's really great news as I took the thumbs version after reading some pages for exactly our chip that it should only work with that, so I was not focused on trying another variant or reading about it. As soon as my situation stabilized a bit more I will check if that did the thing.
  4. Firmware

    @electric_vehicle_lover: Hi follow all your progress and that's really cool, actually I needed to clean up my workplace during christmas and have restored it only partially for soldering some stuff for our house which I'm currently still busy with. So sorry for my current break, but I need to solder some more items. The latest state regarding IMU is unfortunately that there seems to be a instability when using float, the code seems to run a bit, but then stops and I could not figure out before christmas what it was. I'm also unsure about how to deal with the timing issues and debugging, my current debugging facilities are a bit limited with the aspect of real time, all debugging with the SWD slows stuff down and so can have any kind of side effect. So I already had the idea of using all the leds for showing various states of the code to not have something interrupting the real time behavior. If there are any other ideas I would appreciate it. I'm a bit far away from such a solution, but a serial transmission would also already help a lot as it does not involve break point handling (as all my current methods via SWD). If there are any other ideas for this they are very welcome.
  5. Firmware

    @lizardmech: Simple DIY projects I've seen that already work, only use the angle as input and a motor control value (not further egulated) as output, if angle is not achieved the output is adjusted accordingly. More advanced algorithms, that should result in more stability under different environmental parameters use a speed (rpm) and/or torque (voltage/ampere) feedback that is also PID regulated. In which case there is a back channel, but with common parameters, so from design point of view these parameters if normalized could be passed through a well defined interface and if a motor driver does not support it you could in worst case rely again on just a undefined motor control value and a simple algorithm with just one PID loop.
  6. Firmware

    For later this is fine, search for HC-05, this is a ready all in one bt module for just a few euros and all you need to do is connect power and serial Rx/Tx. This is what I've seen in another bluetooth wheel (china).
  7. Firmware

    I'm just checking this: http://electronics.stackexchange.com/questions/149387/how-do-i-print-debug-messages-to-gdb-console-with-stm32-discovery-board-using-gd In the hope I can get a faster debug output that also doesn't interrupt program flow, as stopping with a breakpoint while I2C transfer is at some 'waiting for the MPU' state, and that state arrives during breakpoint (of course the MPU is not halted :-)) the state may go away and will never be reached again as the flow is broken. With above code I already can transfer characters from the running chip to OpenOCD (but it's also horrible slow, at least the flow is not broken).
  8. Firmware

    Ok, found it (here: https://www.mikrocontroller.net/topic/304369) We have libgcc included since the very beginning and I recently added libm (for math stuff, like trigonometric functions), those libs should be taken from /thumb directory, it just didn't caused problems yet as we seem to not use anything from libgcc.
  9. Firmware

    I read somewhere that there is a chain and WWDG is just the last one, so I actually put in my head 'something is not working' (generally), without care actually about the WWDG specifics.
  10. Firmware

    The F103 does not support a hardware FPU, so I already added -mfloat-abi=soft -msoft-float a while ago, it seems just there is some pice of the puzzle still missing. Well I meant that with just the duty cycle it would be possible to ride (maybe 5-10), the current feedback should be read in and passed to a PID regulation also, to achieve some constant torque. Without that, the main PID may have more difficulties to regulate just on the known speed (RPMs) and can not react so fast on voltage sags, or voltage drain, hills or other slow down / accel forces from outside? WIthout somebody on the wheel, the motor can probably spin up to 50-60km/h (just a small guess), but the tourqe at this speed will not allow riding.
  11. Firmware

    Ok, cool, I think with that we can already soon build a firmware that is a bit rideable! Which kind of problem? I stripped my problem down to passing a float as an parameter and doing nothing more, the code when executed ends up in some exception handler, WWDG_IRQHandler(), I read about various options to the linker, but maybe we are linking against the wrong libs, I also added libm.a and changed LD command to gcc as it does some magic here to avoid undefined symbols from the system libraries.
  12. Firmware

    Glue compiles now at least, but need to figure out why soft float stuff is not working.
  13. Firmware

    Ok, after implementing a proper delay function (added a util.c for that) the MPU6050 raw data can be read and looks quite reasonable already! I continued a little bit with the glue from raw to filter but need some more work on here.
  14. Firmware

    @electric_vehicle_lover: Wow, that's really great. Could you already make progress in the current measuring then or does it run just by duty cycle and hall sensors? Did you use a second board then, if the other is damaged or could you repair it already?
  15. Firmware

    The motor interface is just the hall sensors, so if the operate at the same voltage than generic (which is likely) the other parameters are the order of the hall sensors and the number of coils per rotation, so maybe you can just figure that out and we make a define for both sets of parameters and could already support two motor types!