View Single Post
Old 10-07-2015, 02:35 PM   #2147 (permalink)
Permanent Apprentice
Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 312 Times in 214 Posts
It sounds to me like one of those perfect is the enemy of the good situations.
I've seen things like this with regard to development and compromise:
The 90% solution costs $X + time
The 95% solution costs 2*$X + 2*time
The 98% solution costs 2*2*$X + 2*2*time
and so on...

Most of the time, motors intended for EV use have some form of position feedback. I think that it would be a good place to start. - Use the one on thingstodo's motor.. In addition, if a single speed gearbox is used, the vehicle speed can be directly derived from the motor's position feedback. That saves a sensor down the line.

The cheapest easiest solution I've always seen in app notes is the one using 3 hall-effect sensors. I think that if 1 sensor could be installed, then it wouldn't be that much more difficult to install 3 and have the option of 3 hall-effect sensor code.

Here is where having the code split up for different types of position feedback would give an excellent opportunity for both the final user and software/hardware development.

The sensorless code Paul is working on could also be very useful for "filling the gaps" of information when less accurate encoders or hall-effect sensors are used.

It seems Paul has a very full plate right now. For my bit, I'm going to attempt splitting up the sensorless.c code into functions. I will use all the original variables, comments, programming style, etc. Paul - if this seems helpful, let me know. Also - if you have suggestions, please let me know.

  Reply With Quote
The Following 2 Users Say Thank You to e*clipse For This Useful Post:
MPaulHolmes (10-07-2015), Thalass (10-07-2015)