A huge upgrade for my spinning robots!! (melty brain accelerometer sensor)
Vložit
- čas přidán 27. 06. 2024
- Want your own custom-printed circuit boards? check out the services at PCBWay: www.pcbway.com/setinvite.aspx...
This week we finally added an accelerometer to my melty brain robots!
Broken Link robotics: / @brokenlinkrobotics
Thanks to pcbway for some equipment used in this video:
Hotplate: www.pcbway.com/project/gifts_...
Wire Holder: www.pcbway.com/project/gifts_...
Follow me to see what I'm up to:
Instagram - / _team_panic_ - Věda a technologie
good heading requires gyro..
a few things I'd recommend..
1. add a gyro (only used for self start calibration during the first 1~300RPM this is used to find the offset from center of mass)
2. use SPI + IRQ over i2c SPI is significantly faster and by using A. fixed timer interrupt. Or B. input interrupt the RPM calculations will be far more consistent the main clock is held during the delay function + code execution. i suggest putting all of the spinner function into a dedicated loop on it's own clock possibly use DMA+FPU to hand most of the math so the CPU can focus on servo and led signals.
If am bored this weekend I will rewrite your code for how it is and some code for how i think it can be better. I might just redesign the entire thing as i can think of a few uses cases for it my self
my last and biggest hint the center of the bot and the center of rotation are not the same at speed it will rotate around the center of mass so the accelerometer offset needs to be based on the center of mass.
from what i can tell
your setup is a bit of filtering
1. teensy 2
2. H3LIS331DL on a sparkfun board
I can make you a custom board with a SAMD21G + H3LIS331DL + LSM6DSV16X + USB-C (usb storage mode) + flash for logging test and fight data. it will be smaller than the teensy 2 by it's self
Calculate G for rpm. 1in or 2.54cm from center of mass at 2000rpm
0.00001118 x 2.54 x (2000)² = 113.5888G's = a max rpm of 3750 if the lis331 is set to 400g max.
If you ditched the vertical for a steel cable with a mace on both sides for a 18in total diameter when spinning at 2500rpm gives each mace 1600x there weight in hitting power just a thought. If each one was 250gm that's a 400kg impact not much in that weight class can withstand that and if that's not enough 3000rpm is 2300x there mass or a 530kg impact. It has a lot of potential
Dude, isn't the board he joined to the teensy a gyro?
LSM6DSV16X is gyro and acc. H3LIS331DL is acc. Why?
@1kreature the board he is using is accel only no gyro.
The reason is dynamic range
The accel he is using is a good unit it can measure upto ±400g where 99.999% of units max out at 16g most gyro top out at 2000dps some will can get to 4000dps
That's degrees per second and even 4000dps tops out at 666rpm.
It's the restrictions of the gyros that force us to find other methods like using centrifugal force to calculate rpm. I still think adding a 940nm iron detector in the side of melty and a bright 940nm led light. This interrupt will let the bot correct for drift in real time keeping an extremely tight heading lock.
@@ZoeyR86 Wow, I did not see that! Thanks for correcting me!
Using just accell is hopeless. In fact I'd cheat and also use a IR and light detector so I could record a "360 waveform" of my surroundings and use that for an extra fusion sensor reducing drift. The magnetometer has same effect and can be samples 8000 times a second (MPU-9250) and 2000 rpm is only 33.3 rps giving 240 readings per revolution. More than enough for navigation.
Btw, InvenSense/TDK is a bit vague on if (MPU-9250) magnetometer can actually be sampled at 8000 sps, but some other models can.
Delicious progress! That's so freaking cool. Good luck getting all that tuned in!
Hi Ben, I highly reccomend switching to IR over accelerometer to determine orientation. It's absolute positioning means that cracks on the field or wall impacts or rpm accelerations do not cause drift and offset your headings. Also you never ever ever need to deal with the accel calibration bull crap. Its been working great for my PLANT and believe me, I've tried all the methods. I've been through three different revisions of pcbs with different chips including the mpu6050, AXL375, and magnetometers. I've found that sunlight and reflections dont affect my the sensor and its superior detection means rock solid heading and best in class translation
Going to agree with others, using an accel for dead reckoning in this application is kind of grasping at straws, but using a gyro also likely won't work either due to RPM! You need to infer your rotation and position from an external source. An IR receiver on the bot would be best, so it can PLL a position and/or PID lock it's own speed to that if needed. It's like trying to prove the earth is spinning while still on it, with no stars and sun to reference, and it wobbles more violently than it spins. If it has to be self contained, and an external IR beacon isn't allowed.. maybe consider what sumo-bots do and beacon off your opponents IR reflection, but the walls will cause this as well, so that's a bit more iffy.
put 3 distinct color LEDs on it. Fire each of them at different rates, for instance 1, .5 and 1/3rd so that they create a distinct but basic patter. If visually the expected pattern doesnt show, it would help with knowing if the speed/timing is off. as well as how far off it is.
I don't get why you don't use a 9-dof sensor and fuse the magnetometer data with the gyro.
You get a fairly good heading check with fast gyro response.
Mostly because there is only one mems gryo on the market that can survive/give readings for 2000 RPM and its $50 per chip and they want a minimum order quantity
I think there are prototyping boards for it, but they are more expensive again
@@TeamPanicRobotics That's just it though, gyros are horrible for such things due to drift.
Magnetometers however are excellent if you can avoid them being influenced by everything and everyone (bots) in the vicinity. Try calculating a direction vector from x/y magnetometer once in your bot and see. Magnetometers are a tad finnicky to work with as you must calibrate em in your final bot and they may be a bit wonky on metal battle arenas, but should still be orientable once you select a direction. I used to love using InvenSense IMU's (now taken over by TDK and deprecated).
You should make a fully surface mount board to make it even smaller!
Thats on my list to do for sure, but I want to get it working first
Do you have any way of tracking rotations per minute? Are you using this as part of the melt program?
Thats what the accelerometer is for, by reading one axis, you can find the centripetal acceleration, then you can use some maths to work out the spin speed
@@TeamPanicRobotics I guess I don't understand the read out. I thought the accelerometer would show a constant force once up to speed, and I don't know how you calculate a fluctuating rpm from that value
Isn't there a problem with high variations in acceleration readings if the bot is not perfectly balanced and wobbles around?
Especially with a bot that will get thrown around in the arena by it's own design I would not expect it to stay perfectly balanced after some collisions. So the acceleration readings might change drastically destroying any previous calibration.
Just to be sure that's not the case you could move your counterweight in your test-setup a little after a successful calibration to see what happens ;)
Thats part of why I have a heading adjustment knob on my controller to make small adjustments on the fly if the heading starts to wonder
@@TeamPanicRobotics I have no idea how the accelerometer works, but if you read out the value every few milliseconds I think the values could vary extremely depending on where on the wobble the measurement is taken. It might be nearly impossible to get stable readings.
Would you ever try using something to measure the hz of the vibration of the bot to work out the current RPM? Appreciate that this is totally unsolicited but I thought for something to reliably meltybrain, it should be able to reliably identify the speed at which it is spinning in order to always maintain a direction. The calibration seems like a bit of a bandaid fix because the bot is always going to be under different conditions. It seems like the best way to have to avoid constantly recalibrating is to just collect RPM data somehow?
collecting the RPM data is the goal of any melty design
I tried in my old system reading the wheel speed and interoperating the RPM but wheel slip makes that noisy
Yes the calibration is a bit of a band aid but I think if done right it will only needed to be calibrated at the start of each event