• aditya mehrotra.

chip updates: testing code, watching James Burton, and making 'm step n' slide. [updates]

So there are three goals for today: (1) test the code Ronak wrote with the new scheduler. (2) watch James Burton's video on getting his dog to take its first steps. (3) start working on step/stand trajectories for our robot.

Alternate goals:

(3a) inside the on-disable method, get the robot to follow a "sit-down" trajectory. And a good sit-down trajectory at that.

(3b) inside the on-teleopInit method get the robot to follow a pretty good stand-up trajectory.

(3c) decide if we want to tackle the IMU integration/ROS integration with the Jetson first, or if we want to just use the roborio for now.

(3ci) see if we want to use a NavX IMU or if we want to use the ardupilot IMU for now.

(3cii) start with the leaning/walking programming in the teleopPeriodic system using the joystick controller.

test one: does Ronak's code work

It didn't.

So I uploaded the code Ronak committed after we ended our meeting on Thursday. The good news is his code is much better formatted than mine, the bad news is when I uploaded and hit ENABLE, the error was a fun one.

ERROR: "robots should not quit but yours did."

Yes, it actually said that. Gotta love FRC's error messages. We will probably set up a video chat to fix that (the issue can't be very big, it's definitely something dumb like last time). In the meantime we'll move onto other objectives.

task two: inside the on-disable method and the on-teleopInit methods, let's create a sit-down and stand-up method that will let the robot sit and stand on disable and startup.

So instead of randomly adding points in the init or disable methods, the first thing we did was create a class called TrajectoryGenerator.java (it is an object) that takes FOUR LEGS, into its constructor and is able to generate whole-robot trajectories. A snipped (in-progess) is shown above.

We're going to just try the stand-up generator first. There's no movement class at the moment. We're going to create one of those soon.

So we're getting this error: unhandled exception Java.lang.NullPointerException

edu.mit.chip.robotmovement.TrajectoryGenerator.clearTrajectory(Line 18)

Honestly, no idea what that means - time for googling. I mean, I think this means it's refusing to create the TrajectoryGenerator object, like there's no created TrajectoryGenerator. But I need to ask someone who knows what's going on.

Okay never mind, so what happened was we were creating the TrajectoryGenerator object before we were creating the legs, oops, let's fix.

That's the TrajectoryGenerator class so far. We're going to test stand-up trajectories now and see what comes of them. We've also implemented a NullPointer check to see if there actually is a leg associated with the argument.

fixing the leg (again):

Okay, so the back-left leg is somehow still showing sensor-fault, and it won't even move. So let's fix that first. Once again, it's that stupid encoder cable. Sensor fault, yay! We're really going to need a better solution in the future. I have a feeling there's something wrong with the encoder cable on the front left hinge joint, so while we're at it we will look at that too. Re-do the soldering and insulating for both of them, and then hopefully have no more issues. We'll also tape them/secure them at strategic points.

back to the coding:

So the code seems to be working now that we've made some changes. But there is still a mechanical problem with the back-left leg. I think we'll either need to replace the NEO motor (it works but its being a little weird). Or we need to really grease that gearbox which is a possibility. We might need to grease more than one we have to look into it, but it isn't making a good sound.

fixing the leg (again):

Okay, so for the time-being we've pushed to origin because the code does work as intended. The legs follow trajectories. There are two gearboxes however that are being very annoying. The front left leg hinge, and the back left leg knee. This is after we have "stalled" Both of these gearboxes, so we're going to take them both apart, lubricate them, test the motors, test the encoders, put them back together, and see where we get. We may need to replace the NEOs which would be a real shame. The motors, however, still are turning, which indicates a gearbox problem to me not a sensor issue or a motor issue, I think the boxes need a lot of lubrication and we should check the gears themselves for damage.

But food first! We'll do all this in the next post.

#omgrobots #updates #robotics

0 views0 comments