As mentioned in the text a VESC (hardware version 4.20). There are different manufacturers, like Flipsky and Maytech.

Hi, I have a question related to the AS5047, how do you know if the motor rotates clockwise or counterclockwise?. I use an Arduino to get the rotation angles of the motor, but I can't determine its direction of rotation.

Greeting

I live on less than your budget for one robot, for an entire month. 1000 EUR is not "affordable" unless you are a university or other similar research institution.

Divide by ten. At /least/ ten. I can afford 100 EUR or thereabouts. That's about a month's disposable income for me.

Use crap from eBay and Amazon. Use stuff you can get at Walmart and (dare I say) dollar stores. For example: why the big fancy custom chassis out of expensive aluminum channel and Ikea plastics? Angle brackets and Walmart cutting boards... or, you know, a big plastic tub and a bit of wood or cheap plastic or metal rods (heavy duty plant stakes, maybe?) for reinforcement. Lawnmower wheels from the Walmart garden center are another good idea. They're dirt cheap... and relatively sturdy. Certainly sturdy enough for this.

Electronics? Use sealed lead-acid batteries. The kind APC puts in those battery backups for home offices... 7.5AHr 12vDC. $22 a pop at Walmart. Yes they are heavy. But they have a huge capacity, and you can charge them literally with an unregulated wall-wart and a single resistor. (The caveat: charge time is ~18hrs because you have to do it at the 1C rate if you don't want to make a mess.) Motors should be 12v or 24v. Maybe look into Razor scooter motors and cheap Chinese knockoffs... ditto ESCs. Heck, a full-on homebrew ESC may be a savings here... although don't forget that Mouser charges a minimum of $5 for shipping, and chips from eBay generally just don't work.

If you can be creative enough, it's doable. I think. Go for it!

No response...? Shame, shame...

Hey, nice project! :)

Any specific reason why you use the VESC? I would suggest using hoverboard mainboards. One costs ~17$ and covers both motors. The mainboard can be controlled via UART, I2C, PPM and analog input. https://github.com/NiklasFauth/hoverboard-firmware-hack

There are already some Open-Source Robotics platform projects using hoverboard hardware (one by me :3):

https://twitter.com/TheVale98/status/1109271786888355840

and

https://github.com/Jan--Henrik/transpOtterNG

Hi,

Thank you! When I started this project there were some people trying to reuse the  Hoverboard mainboards, mainly by imitating the gyro boards.  For robotics it's helpful to have feedback in order to do odometry. The VESC is a very good ESC that provides that, but comes at a high price. It was quicker for me to use the VESC and got good results. But I'm very interested in reducing the price and see if the hoverboard mainboards are a viable option. So thanks for your links and input, I will take a look!

Does anyone have checked how well these hoverboard actuators handle lower speeds at 0.2 - 0.5 m/s? These are the speeds you usually want to drive your robot during indoor operation.

I'm a sucker for any project based around T-Slot :)

maybe this is the problem after updating the firmware https://github.com/mit-racecar/vesc/issues/11

After updating the FW I get very strange massages in sensor/core topic. Do you have any ide how to fix this? :-) 

Hi, from reading the discussion I see you found and fixed the issue and that it's indeed related to the firmware. Great work :). 

Hi Roald. Yes I fixed the problem :) It was related to the FW. I remapped the bytes in vest_packet.cpp. Here is the fix if somebody else reads this: https://github.com/raess1/vesc/blob/master/vesc_driver/src/vesc_packet.cpp

But thanks anyways :-)

Hi, I have now everything setup. using encoders as5048a. when i try to control the vesc with morph.hw I now get Dutycycle out-of-range left_wheel and same on right wheel.  Any suggestions on how to fix this?

I read you also had some encoder problem at the beginning. Did it look like this? https://www.youtube.com/watch?v=R189nbmtxeU

Would I need to get shielded cables or what do you think?

thanks 

Robin

Looks more like an alignment issue with the magnet. At least similar to what I had when the magnet/sensorboard position was not perfectly aligned. When I had issues with the cable the values went all over the place. But some shielding is required, I'm currently using a flatcable in which each odd wire is connected to ground.

Thanks. I actually ordered a bunch of different encoders to try out. Which include AS5047P, AS5047D,  AS5048A and amt102v. I will test them all and see how or if they work. I am printing a new test rig now that will be better aligned for testing. I also made a shielded 8 lead twisted in pairs cable now with a S-GND for testing. Let’s see how this works out. :-) happy easter 🐣 

I'm very curious to see how the different encoders compare. Happy easter!

Thanks for the reply! I made an homemade shielded cable from an old network cable with 8 leads twisted in pairs and with S-GND to the Foil and the noise is gone. 

It also took some time to remove the hall sensor filter on the VESC (flier) model, since they moved all the mosfets to one side on the PCB, Making the Layout different from the original. After some investigation I managed to locate and remove it.

But I have problem reading the degrees 0-180. It works perfect for 180-360. I tested the AS5047D and the AS5048A. 

I also tested to use ABI Interface for the AS5047D and that works perfectly 0-360 degrees. Did you have any problem with 0-180 degrees over SPI?

I will try the AS5047P later today and see how that works over SPI and maybe ABI if SPI doest work :)

here is a small video on the AS5047D: https://www.youtube.com/watch?v=VoYjUqWflZY

That's weird... I only have experience using the AS5047P over SPI. But it seems others have this issue as well with that type and using ABI does work (as you already discovered :) ). Check out http://vedder.se/forums/viewtopic.php?t=72

Thanks for link. I'm actually active in that thread. :)

Anyways, I got some tips from Benjamin to ignore the MSB and use 13 bits instead of 14 with the following code in encoder.c

void encoder_tim_isr(void) {

uint16_t pos;

spi_begin();

spi_transfer(&pos, 0, 1);

spi_end();

pos &= 0x1FFF;

last_enc_angle = ((float)pos * 360.0) / 8192.0;

}

With this hack the AS5048A was able to read positions from 0-360 degrees. (Did a fast test on the launch brake ) and I was having some minor problems with noise/alignment. So I will do more tests tonight to confirm.

One would try to avoid using ABI mode since that only gives a valid angle after detecting the index pulse , so SPI is to prefer. 

I also found out the modifications on the VESC is not absolutely necessary. One can Define the VESC  to use HW SPI pins instead (that would saved me a bunch of time) :-)

#define AS5047_USE_HW_SPI_PINS 1

Any success recovering the hall sensor coding?  :-)

Anyways I also ordered some encoders now. the AS5048A and also the AS5047P.  May I ask if you are running a self build VESC´s or did you buy it? in that case from which brand? Did you remove the R11-R13  and jumpered R8-R10 to get the encoders to work on the VESC´s?

Thanks!

Sorry for the late reply, reality caught up and didn't have time to look into the code this weekend. I'm using the AS5047P, if I remember correctly the difference between some models are related to the speed it can handle and also if a magnet is supplied. I think the VESC should be able to work with the different types. I got my VESC from Enertion Boards and had to remove the 3 RC-filters which are there for the hall sensors, so removed 3 resisters and 3 capacitors and added 3 bridges. Benjamin Vedder (the guy that created the VESC) describes this very well in this video about encoder support for the VESC: https://www.youtube.com/watch?v=8CcqD5sw90U. I think you should be able to mount the encoder in the drive train, as long as it has a 1:1 ratio to the output you would like to position. At least that's done for servo's, but then again I'm not 100% sure if the VESC's firmware would support this scenario. Only one way to find out ;).

I'll send you a PM with the code I had, maybe that helps.

Thanks Roald. The ratio between motor and shaft is not 1:1, so I guess mounting them on the drive shaft is not an option. I designed a new mount for the encoders making it possible to mount the magnets on the back of the motor (the motor also have holes on the back, so I can make a small bracket for the mangnet) 

Here is the design : http://a360.co/2IpzNX0

What do you think? 

I have two VESC´s made from R-snake flier model. So i guess I need to do the same mode as you did. 

Looking forward to test the code with hall sensors also, But in the end the encoders may be the way for better absolute position. 

Here is a quick and dirty test of the drive system

https://www.youtube.com/watch?v=rY8JqbOhSeQ

Still doing final adjustments before CNC milling the motor brackets. The noise is cooming from the 3D printed brackets (unstable). But for a first test they suffice. :)

All the best

Nicely designed frame! Good to have the flexibility to add brackets like for the sensors. Only thing I would be worried about is the alignment of the sensor relative to the motors. Since you're using a single bracket for both wheels and the bracket is fixed, you can only align it by changing the position of the motors. But it looks like you can only move the motors in 1 direction and perhaps change the depth with some spacers or washers. Since the alignment is critical for the sensor and greatly influences the smoothness of control I would make the bracket and sensor mount adjustable. Maybe designing a calibration tool to mount on the motor which determines where the sensor board holder should be placed. Again very cool project and lots of progress in a short time!

I looked at the changes I did to implement the encoder and it seems it should be possible to use hall sensors with the current code. Although the encoder position is calculated and logged, the displacement values from the VESC are still used and these are calculated by the VESC also for hall sensors. So I think you should be able to run the differential drive without code changes and simply disabling the encoder in the launch file. This is still something I would like to test as soon as I have some time for this.

Got the VECS´s and motor running over ROS with your morph stack. :-) 

some questions you maybe can help me answer?

1. With hall sensors what Parameter for enabling rotor position publishing should I use? I saw that you use default="encoder"

2. When I try to echo the rostopic /right_wheel/sensors/core and rotor_position I get no values. Is this because of the default="encoder"?

3. Where Can I calculate this values

<param name="left_wheel_ikv" value="8.543328017" />
<param name="right_wheel_ikv" value="8.821034775" />
<param name="tacho_pulses_per_revolution" value="90" />

here is a video of the test: 

https://www.youtube.com/watch?v=f4ZobjZOBfo

many thanks for the ROS drivers! :-)

Very nice progress! And cool project, by the way :).
Rotor position publishing is only possible with an encoder which provide an absolute rotor position, so it makes sense you get no values with the hall sensors. I should have kept support for using hall sensors in the code. I still want to do another test with hall-sensors instead of the encoders to see how it performs. I'll lookup the code I had and add support for both type of sensors. Hopefully I will get to this in the weekend.
I determined the 'ikv'-values by calculating the KV for the maximum dutycycle (I used 95%) for the input voltage. I used the values provided by the VESC for the voltage, ran the motor at 95% dutycycle (without load), noted the ERPM, converted the ERPM to RPM (dividing by the motor poles) and divided the RPM by the input voltage. So in short:

((ERPM @ 95%)/motor poles)/input voltage

The value is used to calculate the duty cycle based on the voltage. But there are probably better ways to do this :).  Feedback is always welcome!

- right motor:
    - @ voltage 41.6V => ERPM 0.95 duty cycle: 9814 => 344,35 RPM => 8,277665317 KV
- left motor
        - @ voltage 41.9V => ERPM 0.95 duty cycle: 9830 => 344,91 RPM => 8,231796675 KV

thanks! :-) And thanks for answers. Let me calculate this values too see what I get. I tried changing the (encoder) to pid_pos and are receiving some values now when echoing the sensor/core. Haven’t looked into it more. My motors use internal pcb with 120 degrees hall sensors. 

So I’f I where to mount enconders where can I get the AS5047P? I found the AS5047D https://www.mouser.se/ProductDetail/ams/AS5047D-TS_EK_AB?qs=sGAEpiMZZMsSgQ5oX0A7uvuLN6qMB2aDFPMW%2fVFC97KeWVyQMYHC9A%3d%3d

And also some other AS5047 with different letters. Will VESC striclty only work with the P type?

I will not be able to mount the enconders on the wheels or the motor.  But I have place for them on the drive shaft that’s uses belt drive from motor (gearing the RPM down) do you think I can mount the enconders on the drive shaft?

Also did you modify the VESC in order to get the enconders to work? I looking for the best possible solution to get exact position.

Thanks

Robin 

Got my new motors up and running now. https://www.youtube.com/watch?v=ha5ucyqyUr0

Any tips & suggestions to make them more silent and handle lower speeds better?  I am running FOC and Hall sensors.

Looking at the VESC BLDC-Tool it seems you have measured the hall-sensors but the values are not applied, since the table for the hall sensors values show 255 only, but the table for the detected values show different values. Maybe applying (and for safety saving and restarting the VESC) will help. When I setup a new motor I always perform:

- 'Measure R and L', followed by 'Apply' in the same row

- 'Measure lambda' (I use 3A, 0.05 dutycycle for the hub motors I have)

- 'Calc CC'  followed by 'Apply'

Then detect encoder (at 3A) for the AS5047 I use, or in your case the Detect hall sensors. Finish with 'Apply' and 'Write configuration' . Then you should be able to test the settings.

Thanks. The motor works fine now :) https://www.youtube.com/watch?v=FVqr6PI0G7I

The hall sensors is working and feeding me data. I will try out your ROS driver tonight and see how it works out :) 

Thanks!

Love this project! What ROS driver did you use too control the VESC simultaneously? 

I created a ros_control driver which controls the differential drive and uses the vesc_driver package from the mit-racecar project to control the individual wheels. You can check the github link https://github.com/roaldlemmens/morph and specifically the morph_hw package. There's still room for improvement to get the wheels to run at exactly the same speed and allow the robot to move in a perfect straight line.

Thanks for the fast reply Roald, Let me have a look at the link. I am going to use two BLDC motor running VESC on my project. I will receive them on friday. Then I can test your package. :)

with 2 motors omnidirectionnal any numbers of wheels chassis are possible