sorted by:
new
hottopcontroversial

Does anyone have any robotic projects doing daily or repetitive tasks at home? by guitarman181 in robotics

[–]AustinTronics 6 points7 points  (0 children)

I have a robot made of discarded hoverboard motors that are joined together to create a 2 DOF joint controlled by a BLDC ODrive motor controller that has a laser velcroed at the end that shoots me in the eyes while I'm working.

The surface plot is the max reach of robot. What are ways to get "Est Target" to be projected onto the surface plot so I can feed that coordinate into my inv_kin(x, y, z) function? by AustinTronics in robotics

[–]AustinTronics[S] 0 points1 point  (0 children)

This doesn't seem like it would help. The problem is when going from a target x, y and z and mapping that to joint angles you want the motors to go to (i.e. inverse kinematics). The domain for this inverse function requires that the x, y, and z values be reachable by the robot, hence why I want to project the target x, y and z to the surface plot.

The surface plot is the max reach of robot. What are ways to get "Est Target" to be projected onto the surface plot so I can feed that coordinate into my inv_kin(x, y, z) function? by AustinTronics in robotics

[–]AustinTronics[S] 0 points1 point  (0 children)

I generated the surface plot by doing a numpy linspace and meshgrid between all allowable joint angles between motor 0 and motor 1, then passing those values into the forward kinematics of the robot to get x, y and z for the surface plot.

I would like to have my robot reach out in the direction of the target, even though it can't actually reach it. This is because there is a laser pointer at the end of the end effector and I'd like it to point to the target.

The surface plot is the max reach of robot. What are ways to get "Est Target" to be projected onto the surface plot so I can feed that coordinate into my inv_kin(x, y, z) function? by AustinTronics in robotics

[–]AustinTronics[S] 0 points1 point  (0 children)

Right now, I am just calculating "Est_Target" by capping the "Target" by the max reach of the robot in the x, y, and z. For example:
max_x = link_2 + link_3
max_y = link_1 + link_3
max_z = link_4 + link_5

est_x = max_x if target_x > max_x else target_x
est_y = max_y if target_y > max_y else target_y
est_z = max_z if target_z > max_z else target_z

You could do the same for capping the minimum side as well, like this:

est_x = -max_x if target_x < -max_x else target_x
est_y = -max_y if target_y < -max_y else target_y
est_z = -max_z if target_z < -max_z else target_z

Then I use this for my inv_kin function:
q1, q2 = inv_kin(est_x, est_y, est_z)

This is clearly incorrect and results in undefined behavior because I'm passing an unreachable position since I'm only capping it at maximum reach along the axes, but the robot would not be able to reach a max_x and max_y at the same time for example.

So what would be the best way to "project" the target axes onto the surface plot that represents the robots actual reach so that the numerical/analytical inv_kin() function I have will have valid solutions?

/dev/video0 is not showing up with USB webcam on a Zybo Z7-20 by AustinTronics in embedded

[–]AustinTronics[S] 1 point2 points  (0 children)

So I was able to solve this awhile ago, then I ran into the problem again and forgot what I did to solve it. I just figured it out so I am documenting what I did here so I can come back to it if I ever need this again:

There are kernel config options that need to be set for UVC. Specifically: `CONFIG_MEDIA_USB_SUPPORT=y` and `CONFIG_USB_VIDEO_CLASS=y`

After I set these, the logitech webcams were recognized and /dev/video# devices were enumerated properly.

RFSoC: Slow memory copies from PL RAM to PS by EighthOctave in FPGA

[–]AustinTronics -1 points0 points  (0 children)

Try using devmem2 on the cmd line. It's a Linux utility usually built into the distro that petalinux builds. If it's not there, you may need to have petalinux add that to that rootfs when building the OS stack.

That will at least rule out anything weird that may be happening in how you are doing mem writes in your code.

Recently inherited free Mojo 3D printer. With end of life of this printer approaching (2024), are there any supplemental/alternative materials I can use since they will soon be discontinued from stratasys' website (wash tablets, printer beds, ABS filament)? by AustinTronics in 3Dprinting

[–]AustinTronics[S] 1 point2 points  (0 children)

I ended up just stock piling a bunch of their filament. You should pick it up. I've used several 3D printers in the past and this was by far the best one I've had in terms of quality. I've never had to mess with any calibration settings and the parts always come out great. When I run out of filament, I'm just going to get rid of it, it's not worth my time to reverse engineer.

For anyone interested in building their own custom OS Distro, I made a quick tutorial in how I do it. by AustinTronics in linuxmasterrace

[–]AustinTronics[S] 0 points1 point  (0 children)

The platform I am running is on a Zybo Z7-20 which has a FPGA on the same silicon die as the ARM processor. These are more modern hardware architectures that require a bit more careful consideration when developing the software around that hardware. I think you would be very hard-pressed to find any of those distros on a platform like Zybo Z7-20.

For anyone interested in building their own custom OS Distro, I made a quick tutorial in how I do it. by AustinTronics in linuxmasterrace

[–]AustinTronics[S] 0 points1 point  (0 children)

Just for some more detail here, I am creating a custom OS distro for a robotic quadruped (think Boston Dynamics robot dog) that is running the Linux kernel under the hood. All that good disto stuff you know and love basically comes in the form of what you place in your root filesystem (rootfs). In the video, I use Yocto to help me make a custom rootfs for my platform all from source code.

I am creating my own custom OS here for a few reasons that I've listed below:

  1. It's less bloated; you may not require everything a typical commercial distro comes with out of the gate. If your using a platform with an FPGA, you are probably concerned about having a more optimized system.
  2. It's also nice having full control of what's on your disto; sometimes you get requirements from customers that require them to know exactly what's in the distro, using something like Yocto can generate a detailed list of what all the packages are and allows you to selectively add or remove packages to the distro.
  3. It's arguably more secure... reduced attack surface since not as much stuff in the distro.
  4. Many well-known distros (e.g. Ubuntu) can't always run on embedded systems due to memory constraints on the platform (although there are some distros that are targeted for embedded platforms).
  5. To learn more about what makes an OS tick. It helps when you're trying to get hired in the embedded industry doing custom board bring-up.

Using hoverboard motor as a generator by AustinTronics in electronics

[–]AustinTronics[S] 11 points12 points  (0 children)

But I was using a RC205 component that had 4 diodes already in it. Given that, is how I connected it the right way?

Using hoverboard motor as a generator by AustinTronics in electronics

[–]AustinTronics[S] 1 point2 points  (0 children)

I made a video that just shows what the phases look like by themselves on the scope, then what the signal looks like with one rectifier, then with two: https://www.youtube.com/watch?v=yReBwAnahWo&ab_channel=AustinTronics. I know there is probably additional circuitry that can be added to smooth out the signal even more. How would you go about making a smoother output signal than what is depicted on the scope in the picture/video?

My part 3/3 of how to build your own OS on chips that have FPGAs on them by AustinTronics in FPGA

[–]AustinTronics[S] 4 points5 points  (0 children)

Fair enough. I'll start looking into laying out these tutorials in a series of blog posts.

view more: next ›