@evandthayer 3 ай бұрын
instead of syncing the jetson and the teensy, have jetson add commands to the end of a queue, and have teensy pull from the front of the queue. as long as jetson is running faster than teensy, the teensy will be real time.
@harrisonlow 2 ай бұрын
I do like this idea, though I'm not sure it's as robust as a proper RTOS on the Jetson. I think what you're suggesting would be fine for purely open-loop control, though once we add in some feedback and need to make quick changes to the trajectory, I think this approach might struggle to update in time. What do you think?
@evandthayer 2 ай бұрын
@@harrisonlow a proper RTOS is certainly more robust. In my uneducated opinion it might be easier to rely on the fact that the Teensy is a microcontroller and is never burdened with outside processes during execution, therefore ensuring a stable instruction stream, instead of implementing RTOS. I am not an expert on state-based controls (although I have dabbled on a few balance projects), but it may be worth a trial? I may be over-simplifying. And you may just want to implement RTOS for your growth as an engineer. I am subscribed and looking forward to what you decide.
@harrisonlow 2 ай бұрын
@@evandthayer Yeah the tricky thing is that adding the Teensy as an intermediary isn't trivial and I think will require more work than it's worth, especially given that I'm somewhat committed to changing the Jetson over to a RTOS eventually (once we actually hit the limits of the current setup)
@evandthayer 2 ай бұрын
@@harrisonlow I agree that you've got too many variables to willingly take on a fundamental hardware change. Do exactly what is the most efficient for you!
@darkmann12 3 ай бұрын
49:11ish - not necessarily a solution, but - something in the hand is based off of the assembly in order for it to have its offset. if you can break that dependency in a way (i.e. remove contextual reference from the part), then the change will reflect in the assembly immediately
@DennisBouw 3 ай бұрын
Something feels off about the results of the simulation. Imagine the platform with radius 50 mm, moving one actuator a tiny bit will rotate the platform by a lot. Taking into account the inertia of the platform, the force required by the arm is huge and needs to be very stiff. It will be very sensitive and vibrate a lot. Maybe you could separate linear and rotational results of the simulation. Btw, I love the way you're approaching this. Using simulations for optimization is a great way to get the most out of juggle bot
@---.. 3 ай бұрын
Since you mostly move the hand and the platform at different times, having separate CAN busses for them seems like it would be a waste. Can you just get the platform to hold position and leave all the bandwidth for the hand when doing the throw?
@harrisonlow 3 ай бұрын
That's a very good realisation! I think you're right and this will be a much simpler way to do things for now. Once we start doing some more complex movements with the hand and 'arm' (/platform) moving simultaneously, we may need to add a second bus like I describe in the stream, but at least we'll know a lot more about the requirements of each subsystem by then if we do things as you suggest. Big thanks for this suggestion 😊
@yeroca 3 ай бұрын
Excellent thought! I love it when a problem can just disappear like that "for free".
@kingding7715 3 ай бұрын
I think for the simulation it should be enough if you only check like 120° (I'm not sure aboute the actual number) of the cone since the platform is symmetric. 🤔
@jonbeno9926 3 ай бұрын
This is correct! Actually, it's even better than that. There is radial symmetry repeating at 120 degrees, and within that segment it is symmetric about the center plane of that segment, so analysis of only 60 degrees is required.
@harrisonlow 2 ай бұрын
Yes very good pickup! Though it's interesting to note that some of the 'strange' points where condition number skyrockets only appear in certain regions and not other (radially symmetric) ones 🤔
@supernumex 3 ай бұрын
Buy a second Jetson and install the RTOS on that.
@harrisonlow 2 ай бұрын
If money were no object, this is exactly what I'd do 🤑
@DennisBouw 3 ай бұрын
Something feels off about the results of the simulation. Imagine the platform with radius 50 mm, moving one actuator a tiny bit will rotate the platform by a lot. Taking into account the inertia of the platform, the force required by the arm is huge and needs to be very stiff. It will be very sensitive and vibrate a lot. Maybe you could separate linear and rotational results of the simulation. Btw, I love the way you're approaching this. Using simulations for optimization is a great way to get the most out of juggle bot
@harrisonlow 2 ай бұрын
Yeah I agree there. To be honest, I've spent so much time coming up with explanations for why some geometries might be better than others that I think I've confused myself and find it hard to trust any of these thought experiments anymore 😅 I also can't think of where the simulation ought to change if there is a mistake with it 🤔 I've been fairly convinced out of my 'norm score' method and am now prioritising the condition number alone (as a result of a discussion on Zulip), but even the condition number suggests a smaller angle and radius will give a better conditioned platform 🤔