Author: jsamulak

Teleoperation Success!

There were two issues that I ran into upon integration testing the frame housing that prevented locomotion:

1. The space between the front plate and the wheel attachment piece was too large, and it caused the wheel to twist and get caught on itself when spun. This was fixed by increasing the thickness of the bottom front plate ring to hold the wheel piece down. I thought having more would be okay with the wheel holding it on the other side, but then it would have been more friction as the wheel being the primary method of holding it in place would drag much more.
2. The gear train required too much torque from our motors. As a run down of the diagnostics: a) the friction was minimal with PLA on PLA (after fixing issue 1). b) The rods we used were very form fitting with the gears spinning very nicely (I had made another little piece with various hole sizes to test which would be best before making the full print). c) The spacing between gears was all correct, as the gears could spin well using our hands, but it was difficult to spin them. So the solution for this was to change the gear ratio between the gears. I made the motor gear smaller, and the corresponding one larger to match, so the design didn’t have to change much and we could still use the rest of the print we already had.

Old:                                                                     New:

(there are also a few other issues that were addressed, that weren’t strictly necessary, but just make the bot better to work with. 1) Some holes were hard to screw into, so I made them slightly larger. 2) the sensor frame holder broke, so while duct-tape does work, I went ahead and made the frame a little thicker with more support. 3) the 3D model from online didn’t match the motors perfectly in length, so the snug fit works, but is slightly misaligned and required some physical *ahem* adjustments to mitigate that.

And now it works!! We have minimal media space for our website, so linked below is a full teleoperation integration test over WiFi using our keyboard and ROS topics:

teleop-spinning

teleop-extended

Next Steps

Mainly, print our second bot with the now fully verified design. Then as that prints, also to help the team in refining our algorithms for the actual movement (and getting our actual full system documentation together). At the moment, it just maxes the voltage output forward, backward, left, right based on arrow key presses. This isn’t too conducive for autonomous or waypoint following. We have begun this process already, and Adrian talks to it more in his report.

Full gear train housings printed and tested with our wheels and all other parts as necessary also in place. Housing adjustments also made to make space for wires and solder imperfections.

Final assembly is slated to be finished tomorrow, where proper integration testing can finally ensue!

Completed work:

Housings are in progress, and electrical condensing is following suit.

UWB locationing is largely completed, only identifying air tags is left, and then coming up with a calibration process for the full bot setup once completed.

UI is successfully taking the data generated by the UWB and other sensors and displaying those data points on a map. Next step is to add a Kalman filter to combine our data properly over time to refine itself.

Goal for this Week (Teleoperation Prospects):

The goal is to have a bot fully operational and teleoperated by this Wednesday! That way Brooks and Adrian can move from testing in simulation to testing in reality. Housing has good progress, and I believe it reasonable to finish by Wednesday.

For electronics, we have already tested motors and getting data over WiFi, so it is now a matter of combining those principles to become teleoperation. We also have a camera on our ESP board, so that is a new thing to get working, but should not prove too difficult.

Risks:

Most risks have been seen and mitigated for. One of the bigger ones for our system is the fact that we only have 4 bots at best, and therefore are limited in our demo. However, we decided to separate the precision localization from our search algorithm to show off how the system will perform with many more as intended.

We will in one case have most bots still acting as anchors, while one or two move, and show the level of precision you can have. Then, in the other case, we will just have them all go out and search, without caring as much about the localization with respect to the global frame (as that was already proved possible with the first part)

Mechanical:

My method of developing the housing is iterative, where I make pieces, make sure they work, then move on to the next piece that uses the previous. I have gone through three different prints now (only the third having the “motor cap” once I was confident that the motor shape was form fitting), making adjustments as needed. I have gotten a housing that successfully houses the battery, snap fits together, all of the sensors and PCB boards have mounts. The only thing left is the gear box and wheels!

Here is the third print:

Here is a view of the current Full CAD assembly view:

Electrical:

We will be using the following empty PCB boards to hold our electrical components:

(Note that annotations of wirings are not yet completed, but they will be soon using our past diagram:)

We need to have a short meeting together still to discuss adjusting pins to make housing wiring easier, but since the housing specifics are mostly done by the end if this post, it should be done by Wednesday.

Next Steps:

I want to have a full bot up and running this wednesday!

Electrical Developments:

Before getting to the CADDing, I wanted to be sure how we were wiring this all up, and then therefore what wiring space I would need to take into account while making the housings.

IMU / I2C wirings:

H-Bridge specific Wirings:

All components wiring diagram updated to included capacitors:

Y-splitting the battery connector out so we can easily distribute to all other parts.

There’s more, and I believe we may have some videos for our team post, but basically I oversaw all the electrical work (so it was a group effort in soldering up all our parts, but I was delegating, as this is the part we’ve ascribed to me having ownership over), and it’s all looking great!! This last complicated one we only did for one battery, as it felt a bit sketchy, but all our motors and sensors have their wires and pins soldered up!

I know we spent a lot of time considering all components, and making sure that it would all work. However, I was pleasantly surprised that when we actually put it all together it just worked. Props to brooks for getting software working near first try!

Housing Developments:

Due to spending more time on the electrical work, the housings are unfortunately not finished yet. It is looking unlikely that a first print will be finished by Monday, but I want to still have a 3D model to show for the presentation (to also talk about improvements/extensions), then a print done Wednesday.

A few new things that also caused reworking:

1) our motors are 20 RPM, not 20 RPS. So a gear up is in order. Figured out how to make and port over gears, so now just need to figure out what ratio we actually want/need. (see double_helix gear below, using a plug-in for onshape I found:)

2) we need to order wheels / a ball caster. I thought we could 3D print them, for some reason, but for good grip we really should just order them. I found a good set that should work for all 4 bots, and submitted an order to them. It will take some fenagling to get it on nicely.

3) our electrical components are rather loose. I was thinking we would make use of the pins as a sort of holder for them, and then use female to female jumper cables, but this takes up a lot of space. Instead, we will be using a series of empty holed PCB boards with mounting holes. This makes it much easier to connect all our components together and hold them in a compact fashion.

current tentative placement of all electrical components (plus wheels) in onshape:

CAD Progress

Started CAD files for the robots. For this week, mainly searching for existing models and importing all parts I could find. Then, measuring and making approximate stand-ins for the remaining parts. Also shared it with my teammates, so they can see the progress as we go, and maybe also help the design process if need be.

I have already been considering how we will be attaching things, gathering standoffs and such. The next step is to arrange the models around for proper CAD housings.

Electrical Progress

We got our LiDAR working! Adrian and I are mostly up to speed with Brook’s programming stack he started working on earlier in the semester, and now we’ve started using it to get our pieces working.

^^schematic for easier understanding of the mess of wires (not including 5V power lines, just the pulled up I2C wires)

Deliverables

Next week I want to have the full CAD done and printed for demo. I want to have a first prototype print done by this Wednesday (2/25). Robo Club had to order new filament, so this may be pushed back, but it hopefully won’t impact the critical path, as I can just do other class work first instead.

By the Interim demo (2/29) I want to have started integration testing the electronics with the finished CAD model.

All our parts came in! (minus H-Bridge) With the parts in hand, it is much easier to come to a complete arrangement of what our system will look like.

This post will give a play by play of each components update, here’s the electrical chart again for reference:

Physical Connections:

Battery Connections: While RoboClub had batteries, we need to connect them to the rest of our system. First step is getting some wires with female tamiya connectors. the Tamiya blocks were available in RoboClub, but I had to strip and crimp some wires to them for us. See below. (While we don’t need all of these right now, it felt inefficient to just do one and leave the rest as a task for later)

The next step plan for each of these is to t/y-split them into their own step down and H-Bridge components. H-Bridge isn’t here as needed, so we will do that later. No impact to critical path.

LiDAR Connections:  Cord was provided in the purchased kit. They easily plug into the ESP pins.

IMU: the LiDAR pack had extra wires displayed, so I had initially hoped I would be able to repurpose them, but unfortunately we cannot, as the LiDAR is SPI compatible, which means it has extra wires and is not a purely I2C connector with only 4 (doesn’t fit into the IMU plug). Therefore I need to make new wires.

UWB: UART connection to the ESP is being handled by Brooks, seems to be going well.

H-Bridge: Problem was caught upon closer inspection of this choice once I had all our parts in hand. Our current option takes 5V for it’s control input, which is problematic for our ESP 3.3V option. This does not impact critical path, as other components have sufficient work to complete amidst reordering.

Drivers:

Battery: No drivers needed for battery connections.

LiDAR / IMU: Drivers will have to be made by us (me lol), I2C protocol will use a library for data package delivery and initialization.

UWB: Again, Brooks is largely doing this.

H-Bridge: Pivot to new component means we can’t do this yet, but it will need a driver.

Housings:

While considerations have been made (and standoffs/screws acquired for some components from RoboClub), I believe it best to have our electronics working and wired before I build housings for them. Evidence of this being a good decision already is our H-Bridge change. While components are very unlikely to change now (I am fairly confident we won’t), I would like to evaluate things like how far the LiDAR can actually see for position and placement considerations.

Next Steps:

Our critical path is getting strained. I anticipated this, and as Adrian has limited work he can do before this is done (and is the subject to which this strain effects), I have asked Adrian to help with the effort of this integration.

Design State:

The largest point completed was our design document, in which we didn’t necessarily make a lot of changes to our design, but we did finalize our particular parts/algorithms to use to satisfy our design.

All together, we refined our Design Requirements using detailed Use Case Requirements (see our design doc). With these linked, all of our design decisions are much more easily justified, and clearly purposeful. Also, Josh picked and ordered all final parts and Adrian researched and decided on the frontier-based exploration strategy. (See their respective posts for details)

Because we got access to an ESP early on from roboclub, Brooks has been continuing work preparing code we can port over to the incoming parts that will work with our system.

Risks:

The current critical path is getting our parts. All parts have been ordered, so it’s just a matter of waiting, but Brooks can’t test certain aspects of his work on the UWB module until he has that in hand. Josh also can’t test his housing designs until parts are here. Then, Adrian can’t test his algorithms in the real world until Josh has completed a full prototype with parts.

A risk that also comes with this is that some parts may be dead on arrival. However, since we have multiple parts for multiple bots, but only need one of each to start, this risk has minimal effect. A bigger risk is if the parts don’t function as needed, but substantial effort has been made to evaluate the parts being used, and all vendors are trustworthy, so this risk has hopefully been mitigated.

Schedule Changes:

Despite waiting on parts, progress is steady and on schedule, as we all have work we are doing while waiting.

Global/Cultural/environmental considerations

As described for this particular report’s rubric, we have split these considerations between us and appended our considerations to our individual status reports. Part A was written by Adrian, Part B was written by Brooks, and Part C was written by Josh.