Did any one of you had success using the as5311.
After trying 2 chips from ams and two chips from mouser. I still cannot get the chip to work.
When stationary and looking at the pwm signal it looks good.
When moving the motor a bit by hand I see the pwm duty changing. So the chip works.
While looking at pin A and B I get allot of garbage.
Based on documentation they implemented Incremental Output Hysteresis.
But what I’m seeing on my scope looks like the sensor thinks the motor is moving, vibrating. The motor is not connected to the odrive it is stationary.
So anyone succeed with this sensor.
I’m thinking to drop this sensor and use a traditional encoder connected with a timming belt.
Once I got it working it was working very well for me. I used this breakout board from mouser. There are two things that I didn’t find obvious that I can share.
The sensor center is not in the center of the package, is slightly off to one side. You can see this in the datasheet, and the dotted line on the breakout board.
Problem solved, on my board I connected prog pin to gnd. Also mention in manual. And it worked.
Also I notice the further you go from the sensor with the magnet the more movement is detected by the sensor.
I notice with my hovermotor there is a bit of play. The axle can move in and out by 1-2 mm.
Can only be noticed when you pull on it. The magnets is holding it back.
I’m going to test it else I still have the timing belt solution as a backup if this does not work.
I think we will make hall effect encoder input available within 1 month, so then you should be able to use ODrive directly.
Are there any news related to the implementation of the hall effect sensors?
For a 30 pole motor we would get 90 state changes per rotation if the hall sensors were used as three phase digital encoders. However this would allow only for a very coarse slow speed commutation (4 mechanical degrees per step, or 0.9 cm on the circumference of 10" wheel). I doubt this is how it is done in the hoverboard since it balances very well.
Could the hall sensors be instead sampled as analog values and used the same way as back-emf values to calculate the rotor position? I think this is how it is done in the hoverboard since there is nothing else attached to the motor/wheel that could act as an encoder.
We have been discussing recently (again) with some friends the benefits of all of us having the same motors and drives on our robots so this topic has arisen again. The slow speed performance is important for differential wheeled robot when trying to point itself in a certain direction. I guess, from reading this forum, there might be more people interested in making these motors work with odrive and without an external encoder.
TL:DR - It will work fine at low speeds. If you are REALLY needing fine position control you will need an encoder.
I am not an expert on controlling a BLDC via Hall sensors. However I have implemented Field Oriented Control with BLDCs. The method you suggest is basically how magnetic encoders work with a diametric magnet that senses the orientation of the magnetic field to get an absolute position. But I will say that I am fairly certain that the hoverboard does use the simple method of commutation by just watching for the hall transition pulses across the poles. It’s enough to handle the startup torque at low speed. In general with the hoverboard you can safely assume whatever the simplest way possible for the most part is what they use… I think @madcowswe idea is to make it consistent with the way the rotary encoder and using some velocity to estimate position of the motor to gain back some of this “lost” information.
Yes, we just finished a demo using it, you can expect it to come out with firmware v0.4.0 or v0.4.1. The 90 states per rev makes for quite smooth velocity control, and decent enough for basic odometry.
Actually the signals are digital halls in the hoverboards, but you are also correct that it’s not used for the self-balancing. They use gyro sensors as primary feedback, the hall’s aren’t used in the control loop, just for commutating the motor. The primary control loop just demands votlages or currents (not sure which one) in the motor directly.
Will the new firmware allow a combination of hall sensors and encoder? I already have the as5311 installed. But would like to use the hall sensor for position alignment on startup.
Ok. I’ll use only encoder for now, and do the calibration on each startup, and we’ll see what happens in the future about indexing, or maybe a low power mode to count pulses when the vehicle is not in use.
What configuration settings do you recommend for the hoverboard motors? I installed the first motor today, but got DRV fault, so I’ll do the cap modification tomorrow.
So actually the high inductance of these motors and the noise of the current sensors means that there are stability issues with the current controller at the hard-coded bandwidth. You can take a look at the powerwheels branch, but unfortunately you will have to figure out what’s going on. I can’t support it right now, if you can’t get it to work you will have to wait until I have integrated the hoverboard wheel stuff into devel and I have added documentation.
Excellent, we received in Brazil an odroid v3.4 about three months ago and we are trying to make it work with these 6.5 "wheels. Now I see that the question is very complex, do you have any tips or parameters that can help us?
Fantastic, here we have the wheels BLDC and Odrive 3.4, if there is any test that we can do or collaborate please let us know we will do it quickly and return the result
@alexisdal, @lince: There is now a preview for the hoverboard motor config writeup here.
@walterinho: I think I will use some sort of home switch. This has to be accurate to within +/- 1/128 turn, because the magnet ring has 64 index pulses per revolution.
Great, we’re trying to make it work with the preview but it’s not working.
We are using an ODrive 3.4 48V with an hoverboard wheel, hall sensors conected to
A, B, Z,
We are not using an aditional encoder, is that OK?
We have a magnetic encoder already but is a AS5040 and there are only the AS5047p in the list
