Jump to content

pst

Full Members
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

37 Excellent

About pst

  • Rank
    Member

Profile Information

  • Location
    Detroit, MI

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Catching up again. I agree CAN is overkill (and for the curious, they spec the data rate of the bus, not the data rate of the payload). The MPU-6050 supports I2C which is extremely common, and I would be a bit surprised if other gyros/etc. would not support it. I think most "classic" ESCs use PWM or some other protocol which can be easily "bit-banged" so I don't think it needs to be fully black-box in the HW sense, just agree on a HW protocol, and a suitable abstraction layer for the data to be handled internally by the algorithms. For example, "here is the 16 bit signed value of data in the pitch axis"... not "read the value of register 0x3B and 0x3C and interpret it as twos complement". And if someone wants to come up with a hardware design that is off the wall, they'd simply have to build in an I2C interface - simple enough - and supply a suitable driver to map to the standard/agreed data interface. Same with where the motor controller lives. Whether it's on-board, or several inches away, PWM will not barf. Or if you want to create a fully new motor controller, have it work with the same pins and use a custom driver. Maybe set aside some pins (either near the same port, or just GPIOs) for feedback in case you want to have some custom data signals sent back. Same with charge control, battery temp monitoring, maybe even cell monitoring if you want to get fancy. Or multiple things can live on I2C, as another alternative. Then the algorithm guys are free to work on nerdy math (or offload it to an on-chip peripheral if supported by the processor)... the accelerometer nerds can try out the latest equipment as long as it supports I2C, the "human factors" guys can figure out what front panel buttons it should have and whether it should have scrolling LEDs and/or bluetooth and/or multimedia wifi connections and/or an 8-track player, charge port for your cell phone, electric foot massagers, etc. Oh.. forgot to say, yes, avoid an absolute encoder... the angle of the wheel is unnecessary to know, it is another item to glitch and wear out, and actually the precision will be better with a simple hall sensor (or some-such) mounted on the circumference of the motor, where the radial motion will be at its practical maximum. All we need to know is that the motor/tire is turning by X amount, how fast, in which direction, relative to the frame. It doesn't matter to the algorithm which direction the valve stem is facing, for example.
  2. Unfortunately "real life" has been intruding again for me, but glad to see the discussion in the last couple weeks. Just to mention it one last(?) time: It will be hard to make "an open source EUC motherboard" if some people are working on design #1, others design #2, others design #3,... some using one toolchain, others another, etc. Prototyping ideas is great, but unless people work on a common design there will be a lot of duplicated effort. A compromise might be that the "common design" is really a family of building blocks which can be put together by a potential builder... but again that's back to really documenting things thoroughly; what goes on algorithmically and functionally inside each block, and what gets transferred from one block to another. This way some people could design it with an Arduino, others with NXP, others with TI... some with a commercial ESC and others with a self-built ESC which may have some additional features. Of course this approach is not as efficient as agreeing on only one formula. I feel like I am dwelling on the "un-fun" part of planning, and that isn't my intent... but I am worried that without it that there will not really be a coordinated effort, just a lot of parallel ideas. Especially if multiple people want to be involved in coding, then people will need to invest some learning in a new IDE and possibly even money in debug equipment/etc., so again, best to do this only once.
  3. Yes, it is... I'm not sure why this is directed at me. My statement is that people should worry about understanding the problem before they try to solve it. Backwards-engineering is one way to understand the problem... at least through the window of how someone else went about solving it. As you say, it is "a point of reference." Not a full design. So people need to be working on other things in parallel which will help educate us on how to develop a full design, and maybe leave a bread crumb trail if needed to help people customize it in the future for their own needs. Right?
  4. I guess here's where I talk in circles but shouldn't somebody understand the actual design, like the concepts and then the math behind the algorithms, or how to charge a battery and how much power is needed, etc., before we start worrying about square/trapezoidal/sine wave decisions, or what to re-use from drone firmware? At least speaking from experience, I find projects are more successful when they go in the order of design -> algorithms -> hardware decisions -> building the hardware.
  5. Coincidentally, the Monkees episode this screenshot was grabbed from aired a week or two ago. A search for "monkees unicycle" will show several more images of surprisingly high resolution.
  6. Am I the only one who thinks that thing looks a lot like a miniature penny farthing? :P
  7. I don't think they said it "did not depend on rider skills" but rather that "the danger does not go away no matter how skilled you are." I think it's understood that someone with 3 hours of experience is more prone to injury than someone with 3 years of experience... but there are threads here with plenty of stories of experienced riders getting injured, sometimes seriously. In fact, enough such threads that they started the "I had a good ride" thread specifically for the purpose of counteracting it. To some degree this is true of anything, like even experienced people riding a motorcycle might hit a patch of loose dirt around a corner and go down. But there is pretty much zero risk of a motorcycle arbitrarily stopping when scaling a steep hill and sending you over the handlebars face-first into the ground. I think this is the key difference. Exactly - and even beyond being banned, there is a huge assortment of motor vehicle laws that a product must comply with strictly, to be considered legal to operate, generally put in place for the operator's own safety. Seat belts or safety glass in cars come to mind. These laws drive up the complexity/cost of the product. And in the cases where the legal entities miss something, there's always the court of public opinion.... Pintos catching on fire when rear-ended (no harm to the other vehicle necessarily), Fieros catching on fire, Corvairs flipping in a corner or impaling the driver - these were only in very specific situations, but the reputation stuck. Heck, even the battery problems on the Galaxy phones a few years ago. None of these situations hurt other people, some were only in weird isolated use cases, but you can bet this had an impact on the viability of those products in the market, and future products were built (and sometimes mandated) to have safeguards against them.
  8. Hopefully some of those available libraries include motion control such as we're talking about in this application? :) I know in the other thread there was discussion of using a TI chip with a built-in peripheral for, well, more or less exactly what we're looking to do here. On the other hand, while I'm no fan of Arduino, a more practical benefit is that more people probably have the ability to program it at home, especially if you put a proper bootloader in the image... rather than buying a new IDE and programmer to support another platform. One thing I'm hoping that will come out of this thread as it evolves is some kind of discussion of the algorithms for such control, and some notion of how to make a "good" motor controller... don't know if anyone has references to such things to start thinking about it now?
  9. Yes, obviously you need to maintain your balance, on a balance-controlled vehicle. This is true no matter how many wheels you have.
  10. I'm happy to see the initiative/progress too, but not quite clear if this is mean as an open source project, or a "backwards engineering for personal use" activity? Or maybe a little of both? (Fact finding to inform a future open design?) I'm not sure many people in the open source community will have access to Mentor Graphics, for example - usually they'd use KiCAD or Eagle.
  11. Seems the link no longer exists? At least it gives me an error when I try to open it.
  12. Hey all... per my comments in the DIY thread, if you have a beat-up or malfunctioning (or dead, or just unused) wheel that you are looking to unload, please get in touch, as I am looking for a couple of motors or even complete systems to hack around with a bit. Also I am in need of a control board and/or I/O board (with the "springs" and light sensor) - working or not - for a KS-14C. Thanks!! EDIT: I should add that I am of course willing to pay some reasonable amount for units and for shipping. But since I'm looking primarily for parts units, I'm not looking to break the bank.
  13. Exact quote of mine from the 2018 thread: "I have decent ability in firmware (and hardware) but unfortunately not a lot of spare time due to work. Still, if you have a good understanding, let me know and maybe I can help." So, anytime people are ready to get something together, let me know. I am a little lean on the control theory but my degree is in SW, and I've spent several years building "embedded stuff" (SW and basic HW) for various employers. No matter who does what, like I said in @KuphJr 's recent post, I would really suggest coming up with a well-documented design which is hardware-agnostic first. And that certainly does not require C knowledge.
  14. Welcome to the group. It might help to have one "introduction" thread, and then a second about the project (or you could add to one of the existing related topics). There are a couple threads floating around about related ideas... the one above about a controller, and another about building a whole wheel: Like I say in that thread, I am happy to help out with some such project too, though my time is (still) a bit limited. Not that anybody asked, but I would suggest starting by coming up with a really good well-documented design (like, explain the battery management (charging, balancing, regeneration, handling bigger/smaller/more packs...), explain the control algorithm, what size of motor it is able to power, etc...). That way anyone who comes along and says "I want an Arduino" or "I want a TI chip" or "I want an NXP chip" or whatever, can take that design and run with it. One of my pet peeves about most so-called "open source" designs is that they really are more build-to-print recipes of HW and SW to replicate one design, which - in addition to not helping anyone learn very much - becomes useless as soon as the microcontroller or power FET or some other key part is discontinued. Then people have to reverse-engineer the hardware or source code part-way to get back to a point where it can be subtly modified and then built up again. Not only is doing design work on paper, and documenting it as you learn, generally good engineering practice, it's also a lot cheaper than making a lot of mistakes in "real" hardware. For a really simple project built on others' building blocks (e.g. TI motor control peripheral), maybe it's less of a big deal, but then you build in a dependency on those building blocks, which causes a legacy/reuse issue. I know this is not really the "hobbyist way" of doing things, but speaking as someone who has contributed to, and attempted to re-use, various so-called "open source" designs over the years, it is really beneficial, and helps get everyone aligned.
×
×
  • Create New...