Jump to content

Recommended Posts

Quick update - been updating the code in little bits here and there in between other stuff, and last night I had some spare moments to load the latest version into the rig and test it.

What I've mostly been doing is working on an 'inertia' feature for the throttle.  In the last version, the throttle was very sharp and the drag brake was solid.  Partly what I want from all this is an easy-to-drive truck, not something that needs a super-delicate throttle hand (like an MFU-01), so my first plan was to smooth out the throttle response.

The Crawler speedo has a built in throttle profile, but it was still too sharp for me, so I've set it to maximum punch - with the Tamiya motor and Lesu reduction box the rig will go direct to full speed from a standing start in what feels like a fraction of a second.  To counter this, the 'inertia' feature turns the left vertical stick into something that feels more like a throttle.  Push it forwards a little and it will accelerate slowly, push it forwards all the way and it will accelerate fast.  Let it return to centre and the motor will slowly ramp down to stationary, until the drag brake comes on.

To get it all working I wrote some fairly simple unit tests in C# before I ported the code to C++.  (At the moment the 'inertia' code exists in a separate class but it might be more efficient (memory wise) if it was refactored into a single method.  More on that in another instalment.)

My tests (basically) were as follows (assuming 0 is stick centre / servo neutral point, 500 is max forward / max speed, and 50 is the adjustable throttle profile):

Throttle at 0, current speed at 0, should return 0

Throttle at 500, current speed at 500, should return 500

Throttle at 250, current speed at 250, should return 250

Throttle at 500, current speed at 0, should return 50

Throttle at 500, current speed at 250, should return 275

Throttle at 500, current speed at 499, should return 500

Throttle at 500, current speed at 125, should return 138

Throttle at 250, current speed at 0, should return 25

Throttle at 250, current speed at 500, should return 475

Throttle at 250, current speed at 249, should return 250

Throttle at 0, current speed at 500, should return 450

Throttle at 0, current speed at 250, should return 225

Throttle at 0, current speed at 1, should return 0

 

So basically this gives a nice linear throttle profile.  At full throttle from a standing start, the motor will speed up very quickly but the rate of acceleration will slow down.  As a scientist might say, the rate of acceleration is inversely proportional to the speed.  Which is pretty much what you'd expect from a full-size vehicle.

It also means that at half throttle, you'll accelerate half as fast as at full throttle, and your maximum speed at half throttle will be half your maximum speed at full throttle, which is also kinda what you'd expect from a real vehicle that is geared to hit terminal velocity before it hits the rev limiter.

I've set up two different throttle profiles - one for acceleration, one for deceleration.  This assumes the truck will be 'coasting' to a stop when the throttle returns to the centre.  The deceleration profile has much more inertia than the acceleration profile - i.e. the truck will accelerate to top speed fairly quickly but will take a while to slow down if the throttle is released.  If you go from full throttle / full speed to zero throttle, it will lose speed quickly to start with but as it slows, the rate of deceleration will also slow.  Unlike Xeno's arrow it will eventually reach a complete stop if no throttle is applied.  Again, pretty much what you'd expect from a real rig.  ACtually, if you set the deceleration profile value to 0, it shouldn't decelerate at all - so it could be configured as a form of cruise control.

I haven't actually run the rig on the ground yet (the garage is full of boxes from last weekend's Tamiya Junkies bash and it was raining outside) but it runs just perfect on the bench.

Also I haven't set up a braking mechanism yet.  The only way to stop is to let it 'coast'.  Previously I had been relying on centre-stick = drag brake, so I need to add a brake profile that is steeper than the current deceleration profile, which will make the rig slow down quicker.  Naturally I want to avoid any on-track accidents, so going full-back on the left stick will activate an 'e-brake' function, causing a neutral signal to be sent to the ESC so the drag brake comes on.  That's been coded but not tested yet.

(Long term) future plans for this feature include adding a second set of throttle profiles for when the trailer microswitch is closed in the fifth wheel.  This means your truck will take longer to accelerate and have a longer stopping distance if you put a trailer on the back, just like a real rig.

Another issue that raised its head again is the rate at which the code executes.  I earlier had some problems when debugging over serial at 9600 baud, with buffer overruns causing the Arduino to pause until the buffer was emptied.  This made the steering very jerky.  Upping the baud to the max of 250000 made it much better but also made it very hard to trace the debug data - there were so many loop cycles per second that my input data was getting lost in loads of static data.  When I slowed the baud down to 11500 it was easier to debug but the throttle profiles got screwed up: the Arduino loop was executing much slower due to serial buffer delays and therefore the profiles were ramping much slower.  I figured it would be hard to tune the profiles if they were based entirely on the speed at which the Arduino can perform its loops, because as I add more features (or as an end user turns features on or off) the loop speed will change.  What I needed was a throttle for the arduino loop itself.

Therefore I have added some code that, after executing the main loop, causes execution to pause (it actually goes into an endless loop that does nothing) until a set time has passed, including the time taken to execute the loop.  Ergo if the throttle speed is set to 10000us, and the code loop takes 500us to execute, it will pause for 9500us before running the loop again.  If I add more code and the main loop now takes 1000us to execute, the Arduino will still pause for 9000us and the overall execution time for the loop will be 10000us.

That basically means the motor throttle profile (and anything else that relies on adding or subtracting numbers during each cycle) will remain the same provided the Arduino can execute its code in less time than is specified for the loop throttle.

OK - this was only intended to be a quick update on progress but it's turned into a technical monolog on my part.  I hope that wasn't too dull and it gets you all excited for a video preview sometime soon!

  • Like 1

Share this post


Link to post
Share on other sites

Another quick update - the code has gone through a bit of a metamorphosis over the last few weeks.  The rig has been on the bench undergoing mechanical and aesthetic alterations and so I haven't had a testbed to work on new features, so I've basically been tidying up the code and sorting out some features that should smooth out the operation and basically make it nicer to use.

Firstly the throttle profiles are now working perfectly (albeit without the switch for slowing the rig down when a trailer is attached), throttle and steering mapping now takes into account the adjustable deadband, so there's no horrible jump when moving the sticks out of the deadband and into the response zone.  I have also added configurable deadband and input endpoints per channel instead of a global deadband and endpoints, so a user will be able to tune the system to their radio, and added per-servo output endpoint and centrepoint adjustment so a user can tune the system if (for example) a steering link isn't the right length.

The good news is that I've just hooked everything up to the rig and it works just fine.  Which is nice.

Next trick is to see if all the lighting still works.

After that it's a bit nervewracking because I've got to start looking at audio...

Share this post


Link to post
Share on other sites

Super-quick technical update - after posting the last update I decided to test 100% of the current functionality.  Unfortunately I'd changed a lot of pin assignments and immediately ran into some problems.

My original plan was to have 8 lighting outputs (front fog, rear fog, headlamp, rooflamp, tail/brake lamp, left indicator, right indicator, reversing lamp) and 6 servo outputs (ESC, steering, 4 aux channels controllable via sticks when in park mode).  The Arduino Mega 2560 has (according to the documentation) 14 PWM outputs, pins 0-13, but pins 0 and 1 are used for Serial 1, so using all 14 PWM outs means I couldn't use Serial 1.  While this was going to be a pain for debugging, it wouldn't affect the final code, so I ignored it and carried on.

Unfortunately I can't get pins 0 or 1 to work as PWM outs.  They will either give a constant 5v or 0v.

It looks like I have various options:

1) reduce the number of aux channels

2) reduce the number of light channels

3) control the lights via digital outs (the Mega has many!)

4) use a mix of digital and PWM to control the lights.

5) use an RGB LED system over a single channel

The reason I was using PWM outputs for a LEDs is twofold: 1) I have the option of adjusting LED brightness in the config settings, and 2) I can change the brightness of LEDs on the fly (for example, sidelight/dipped beam/main beam, and brake light / tail light).  I don't really need this feature on all LED channels so it may be possible to mix-and-match, and worry about adjusting brightness using resistors later.

I don't really want to lose aux channel functionality (some day I might want to control a HIAB crane or similar), and I don't want to have less lights.  An RGB LED system would gain me loads of pin space but the LEDs will be more expensive per unit and the code to control them will be hard to configure and potentially will need re-writing for every new configuration.

So I'm either looking at mixing digital and PWM channels or using digital for everything.  Fully digital will massively complicate my circuit, because the headlight LED (for example) will be powered from 3 different pins - sidelight, dipped beam and main beam.  Each pin will need its own transistor-resistor pair.  Suddenly the vero board that only just fits under a King Hauler bonnet will be too big, and I'll have to have PCBs made for the final product.

In that case, it looks like I'll be using PWM for headlight and brakelight and digital for everything else - and if a light circuit works out too bright I'll have to dim it with resistors instead of PWM pulses...

Anyway - work continues...

  • Confused 1

Share this post


Link to post
Share on other sites

is there an app for this on these new phones?, this is Something!

i still yet to configure the MFC-01 already had a DX8 and after some reading purchased a Carson Reflex Stick 2, that's when i read about the DX6 & 8's could be used.

well back ups are good.

i'll learn it but i'm not liking it:lol:

  • Like 1

Share this post


Link to post
Share on other sites

So - I chose option 4 and reconfigured the code to use digital outputs for all lights that don't need variable brightness and PWM outputs for headlight and tail/brake LEDs.  There'll be some intensity configuration on the PWM channels to do once the final LEDs are all wired up and installed in the body but that's a very long way away yet.

In other news, one of the main things on my hitlist is a failsafe.  That is, if the radio shuts off, the truck should immediately stop.  This isn't just a "nice to have" feature but an absolute necessity if I want to drive at the National RC Truck Gathering - all rigs get tested before going on the layout.

I haven't had much hardware time so I've been working a lot just using thought experiments.  So I set up some code to read the 'raw' input values from the PPM library (bad data is discarded from the main 'latest valid value' method) and, if the raw pulses were 0, there must be an error in transmission and therefore the failsafe should kick in.

Unfortunately it seems how I wish radios work and how they really work are not the same thing :D because if I switch off my Tx, the Rx continues to output the exact same values as it was last receiving on the PPM output.  I've searched online for a solution and, apparently, there isn't one.  So this is another area where the 9x lets itself down.  It does have a configurable failsafe but it doesn't work over PPM.  In fact if it did have a failsafe, I wouldn't have to do anything at all in code because I could juts configure the radio to transmit centrepoint on all channels in event of a failure.

There's the possibility that I could use the PWM output from one of the other channels, attach it to an analog input, and use that to check for a failsafe condition.  I have enough spare inputs.  It's a bit more wiring but it's no big deal.  The other alternative is to splash out again on an FrSky radio module to fit the 9X.

I was hoping this setup was going to be cheap enough that I can have one modified 9X transmitter for each Arduino-equipped rig (I have 5 rigs in various states of build), so if I can avoid having to make the radios any more expensive per purchase I can make each build cheaper.  Given that the idea behind this build was to get Beier levels of functionality for half the price, any place I can save is good :)

Share this post


Link to post
Share on other sites

A couple more quick updates.

1) I moved away from using VSCode's Arduino extension and started using Visual Micro's Arduino suite for  VS2017.  vMicro doesn't really offer much more than VSCode, but after several hours of trying to get VSCode to run a C++ unit test I figured I'd be happier using VS2017, which is where I pretty much live from 9-5 on weekdays anyway.

So I managed to get the code building in VS2017 and even got a couple of unit tests working.  It's a steep learning curve as I can't test anything that uses the Arduino libraries, so everything must be wrapped up in simpler wrappers that hide the dependencies.

My current work contract has finished so I have the next week or five to do whatever I please as long as it's coding-related and of benefit to the company.  So I'm wondering if unit testing in C++ would be considered beneficial...

2) I finally found the courage to start work on the audio system.  This is going to be a very steep learning curve.

I started with mojoEngineSim:

https://github.com/BeigeMatchbox/mojoEngineSim

It didn't take too long to get this running, but it did require a bit more in-depth reviewing of the Arduino datasheets to work out why it wouldn't work from the box.  I'm not sure what device the original developer was using, but the pinouts are different for some of the internal registers.  Once again this goes a little beyond my limited knowledge of microprocessors, but to perform audio playback with a changing sample rate (to simulate engine speedy-uppy-downy) requires the speffic use of some internal hardware magic and voodoo so the actual pin used on the Arduino board is important.  I changed the speaker output from Pin 3 to Pin 9 and suddenly it all started working.

I've now got a whole new bunch of problems to work around, each of which could be a deal breaker and each of which needs to be solved independently then integrated into one single functional piece of code before everything can be considered ready for production:

a) Multi-channel sound.  That is, the main 'engine' channel should play the engine sounds (as well as stop/start sounds) and the secondary channel should play other sounds like reversing alarm, brake effects, intermittent effects like compressor hissing, horn, etc...  (I won't be coding indicator tick-tock sounds because that's a pet hate of mine with other audio controllers.  You can't hear the indicator tick-tocking from outside a truck cab so why should it have a sound effect?)

If it's really not possible to do this with a single Mega2560 then I should be able to do it with two cheaper devices.  The mojoEngineSim code works on a simpler device, so two devices should give me all the audio channels I need.  However space is at a premium under a King Hauler day cab so they would need to be small surface-mount versions.

b) Read audio data from a memory card, primarily because I want to be able to swap sounds over without too much hassle, but also because I'm likely to end up with too much data to store in program memory in one go.

c) Swap engine audio files during playback.  We all know an engine doesn't sound the same all the time.  An engine on overrun sounds different to an engine at idle, which sounds different to an engine at half throttle, which sounds different to an engine at full throttle.  Ideally I'd like a handful of different engine audio files - e.g. idle, overrun, part throttle, full throttle, reversing, and have the code swap them as the throttle position changes.  I may have issues with load times causing gaps in the playback so I might have to work out how to buffer audio files.

d) Control everything from the master truck controller.  Actually I could deploy mojoEngineSim with my current code version right now - I'd just have to split the PWM output to the ESC to a pin on the audio Arduino.  However if I want more functionality, like revving the motor in neutral, horn, reversing alarm, engine start/stop, etc, I'll need to send more data.  I've still got loads of digital outs on the master Arduino and more than enough digital ins on the audio Arduino, so that's one option.  ICSP is a more complete option.  Plain serial communication would probably work too, although I want to keep a serial channel free on the master for trailer control via IR.

e) Amplify the channels to a sensible level.  There are basic multi-channel amplifier boards available for electronics projects but they're not compact.  Building my own transistor amplifier or a 741 op-amp isn't likely to be any smaller on a home-made board.  I might be best off buying a cheap bluetooth speaker, pulling out the bluetooth hardware and rebuilding it into the KH hood.

I think the hardest part will be getting all of the above to co-exist on a single Mega2560 without running out of shared hardware - fun times lie ahead!

Share this post


Link to post
Share on other sites

OK - so I've managed to spend a significant part of today with my head buried in ATmega data sheets and AVR library documentation (several hundred pages each) and all I have learnt is that this is waaaay beyond me.  So the bad news is that I won't be able to code multi-channel audio over a single Arduino Mega2560 myself.

On the other hand, I should be able to modify mojoEngineSim to handle engine start and stop sounds, as well as adding a variety of different engine tones, without too much difficulty and without overloading the available program memory.  I can create a second copy of mojoEngineSim (actually a much more simplified version) that will handle additional sound effects like horn, air brakes etc, and I can use two Arduino Nanos.  Nanos are both cheap and small - in theory I can wire two in the space occupied by one Mega and for a lower price.

Might take me a while to make progress.  Next trick is to order a couple of Unos so I can write all my code and test is back-to-back on easy-to-use workbench boxes before I have to start soldering things onto nano boards.

Share this post


Link to post
Share on other sites

Micro-update - just ordered two Arduino Unos to bench-test the whole assembly and a 3-pack of Arduino Nanos so I can actually get on and solder up a finished product once I'm code-happy.  More to follow :)

Share this post


Link to post
Share on other sites

Another update!

OK, so first, my new hardware arrived.  Two Arduino Unos and 3 Nanos.  I was expecting the Nano to be basically a headerless Uno ready for mounting on a PCB.  Nope.  It's the same spec - same number of pins, same processor, same memory, same overall functionality - but it's waaaay smaller.  A full-blown Mega2560 is about 110mm long by 54mm wide (accounting for the USB socket).  A Uno is the same width and 76mm long.  Both are tall, allowing for the full-size USB socket, power socket and female headers.

The Nano is about 46mm x 18mm, and only about 8mm tall.  OK - that means I've got some close work to do when I solder them onto a PCB, but even so, that's tiny.

There's a PCB-mount version of the Mega2560 and I overlooked it because it doesn't have a voltage regulator on board, but the Nano does - at least it has a a VIn pin - so in theory I can run it off the 7.4v BEC.

This is absolutely amazing news, as I have to try to squeeze 3 Arduino boards under the hood of a lowered King Hauler bonnet along with an LED breakout board and a 3S LiPo.

It's also worth mentioning that Nanos come in tiny little miniature boxes.  They might even look good strapped to a pallet.

Secondly, I thought I'd see if I can run my entire Truck Controller (minus sound) code from a Uno/Nano, because that'll save me even more space (and cash).  Sadly no - it could probably be made to work, but I wouldn't have the 4 spare servo channels.  Not the end of the world and anyone who doesn't want to run any aux channels should be OK - full driving and audio functionality off 3 Nanos is pretty good going, especially as I got a 3-pack of Elegoo Nanos for £10.99.

Thirdly, I had to get a heavily-hacked version of mojoEngineSim operating multiple audio samples as a proof of concept for the next phase of the engine sound controller.  I want to be able to switch between startup, shutdown, idle and various driving tones, but the base version of mojoEngineSim just has one sample stored as a byte array in a header file.  This is loaded into the Arduino's program memory, which is pretty big on a Mega2560 but not so on a Uno.  It looked like there wasn't going to be much space for more header files.

So - SD library to the rescue!  Fortunately I bought a 5-pack of SD card readers a few days ago for just £3.99 and I hadn't yet tried them out.  So, out came the breadboard and some jumper wires and a few different web pages listing demo code for reading SD data.

Following the instructions in the idle header file in mojoEngineSim, I created two new sample files - one a very short drum sample, the other a man saying "drugs" (I'm not promoting drug use - it's a sample from a film that I used in an electro song a long while back, and it was a nice clean vocal sample that was short, easy to manipulate, and would sound obviously wrong if there was a sampling issue).  I resampled them to 16KHz and saved them as 8-bit unsigned raw files onto my SD card.

I then hooked up the SD reader to the Arduino.  It uses SPI, so I don't think I can use SPI to control the audio from the master board, but that doesn't matter - I've some spare PWM and digital pins for that.  Within minutes I was reading my drum data and playing it in place of the header file.  Data is actually read on-the-fly, byte-by-byte, from the SD card - so it doesn't occupy any memory.  (OK, each file handle takes up a little memory and I'm reading one byte at a time, but still...)

So - the good news is that I can switch audio files on the fly and the engine tone player doesn't skip a beat.  Because each file maintains its own stream index the files don't even need to be the same length - I can switch on-the-fly from a short idle file to a long acceleration file.

There's still a lot to do - I need to add some code to read various pins to check for instructions (engine stop, engine start) and change the throttle reader so that it will switch files depending on if the truck is accelerating hard, cruising, or on overrun.  And I also need to get hold of all these files - that's going to be the tricky bit, I think, but I've got a heap of youtube vids to start leafing through listening for that perfect sound effect.

The Drag King is going to have its audio files courtesy of the Bandag Bullet...

Share this post


Link to post
Share on other sites

OK - been a while since there was any update here.  Been busy with work and other projects so haven't really had time to look at the MFC that much.  But anyway, I went to the Bournemouth RC Truckers meet on Saturday and took the Arduino-powered Drag King with me, along with my Globe Liner on MFC-01 and MAN TGX on MFC-03.  It was a good chance to see how well the three stacked up against each other.

After having a play with the Globe and the TGX, I powered up the Drag King and set it free on the layout.

In short - I love it.  I worried about jittery steering, but once on the layout it runs fine.  I think a lot of that is down to cheap servos and play in the stock linkage.  With some mass over the tyres it drives as good as my other rigs.  The inertia-mapped throttle profile is nice, too - I worried that it might feel like it was running away with me, but I think I've got the profile just right, it feels like it's accelerating and coasting like a real truck should.  The only time it wasn't so good is if the rear wheels broke traction.  The club layout is 10mm wood laid over a polished floor.  Trying to get the truck from the floor back onto the road panels involved spinning the back wheels.  Due to the coasting profile, when releasing the throttle the wheels continued to spin, which looks a bit weird.  Also once the truck had successfully hopped onto the road panel I'd release the throttle, but as the wheels gained traction it would speed up.  A quick tug on the brake would slow it down but it's something to keep in mind when operating.

Because of the planetary transmission on the Drag King, the rear axle won't turn the motor, so without a throttle profile the truck simply locks up solid when releasing the lever.  Last time out I found it quite tricky to drive that way.  I like the inertia profile.  I might also try setting an infinite mass to see if I enjoy the 'cruise control' driving style.

Before the day ended I hooked up the race trailer from the TGX to see how the Drag King / Arduino combo handled towing.  I can honestly say the short wheelbase, complete lack of transmission lash (compared to a Tamiya 3-speed), immediate throttle / brake response and ability to flick between FWD/REV gears on a switch made it a real joy to drive with a trailer.

Unfortunately I did experience more problems with the motor cutting out.  I'd be driving along happily and suddenly the motor would brake, stopping the truck completely, before accelerating away again.  It only started doing this after I hooked up the trailer - unless the trailer was interfering with the radio signal (unlikely, as it's a mostly plastic trailer) this means the problem is worsened by adding load - there's nothing code-specific about attaching a trailer.  The more I drove it the worse it got.  I switched to a second battery and the problem went away, so it seems that some of my radio problems may be power related.  The Rx should be powered by the 5V pin on the Arduino, which itself is powered by the 7.4V BEC from the ESC.  It's possible that as the battery voltage drops, the BEC output drops off, either causing a brownout in the Arduino itself or in the Rx, if the Arduino can no longer supply 5V.  It's also possible that the jumper cables that I'm using can't handle the current, although I doubt the Rx pulls much in the way of current.  (Remember the steering servo is powered by a Y-lead from the ESC BEC, not from the Arduino).

Anyway, I need to look at a better power supply for the Arduino.  I'll have to check the specs to see if I can run it direct from the 3S LiPo and ditch the BEC altogether.

I couldn't test the lighting functionality as I don't have the LEDs or distribution board wired up yet, and the sound system is still rather buggy so wasn't connected.

I've also noticed just how efficient the Tamiya units are at channel use.  All that functionality on 4 channels!!  I'm using 6 channels to get less features.  I'm considering using a Tamiya-style input to switch on less-oft-needed features like engine off / engine on / utility mode, and light modes.  I still like having my FWD/REV select and indicator lights on 3-way switches, although I might relocate the switches so they're easier to reach during driving.

Still a long way to go but I'm very happy with how it's gone so far :)

Share this post


Link to post
Share on other sites

my popcorn is gone!

can you post Pics of this apparatus, i really want to see this brain of yours......................................😵

Share this post


Link to post
Share on other sites

Hi @ACCEL, it's been a while since I had the time to look at this, but I'm hoping to pick it up again in a couple of weeks.

I'm off on my family hols on Thurs so there won't be any RC-related updates from me.

The Drag King and the MFC were been mothballed through May while I got my scalers ready for the Recon G6, and since I've got back I've been completely zero funds and struggling to work out what I should work on next.  It occurred to me this weekend that the Drag King needs minimal cash spending because I already have most of what I need to finish it in haulage form, and the MFC doesn't require too much investment besides time.  And right now I seem to have enough of that that I can't fill it with anything besides watching films and drinking alcohol.

So - I'm going to temporarily park the audio output part of the project, a) because I was finding it really frustrating and 2) because I'm going to have real packaging problems in my haulage-spec Drag King.  Instead I'll be focusing on getting working trailer lights.

One of the main attractions of making my own MFC was being able to connect multiple rigs to multiple trailers and have fully-functional lights without any cables or reconfiguration.  I was planning to do this with IR, same as Beier, Servonaut and the now-discontinued SSTronix conversion for the Tamiya MFUs.

When I get back from my hols I'll place orders for an IR LED, IR receiver and Servonaut IR receiver clip / hollow kingpin.  I might also be able to manage a motorised leg kit, as I'll need the fifth wheel, servo mount and coupler switch.  The legs will get use on my flatbed trailer, but the first trailer to get the MFC treatment is likely to be a Bruder low-loader conversion that I bought from another local trucker last year.  I'll use an Arduino Nano to read the incoming IR signal, control the lights and operate the support legs remotely.  I'll have to build a custom solution for the Bruder legs.  There should be plenty of channels spare to operate things like automatic ramps as well, when I eventually get that far.

Watch this space :) a

Share this post


Link to post
Share on other sites

I have noticed the 12miles of wiring it takes for these rigs:lol:

i'm glad i jumped into other builds so the PGH gets a slow but special treatment when i throw on my visor and grab tools to work on it. it's the foremost reason why i came here and now a 500 dollar truck has turned me into a mad alchemist.

well you have a great time what ever you do.

look forward when both our rigs are complete.

Roll On!

  • Like 1

Share this post


Link to post
Share on other sites

Wonderful work !

I am just finished with my Scania build and now I want to add light.

I have done a little programming before and wonder if its possible to get the code for this project ?

Maybe I can contribute with code later on as well.

Share this post


Link to post
Share on other sites

Hi @Quart, it's been a while since I've had any time to look at this.  Before the last outing I considered it a "code complete beta" but during the last outing there were some issues with power so I want to do a bit more work before I let the code out into the public domain.  I'm not sure when I'll have the time as I'm buried with other things right now.

If you PM me with an email address I will share what I have, you're welcome to take a look, but I might not have time to help with wiring or code support, depending on your experience with coding and Arduino (apologies if you're a pro :) ).

If you want to wait until I've got it uploaded to github then there will be complete wiring diagrams and lots of supporting documentation to help you get started.

 

Share this post


Link to post
Share on other sites

@Mad Ax I have done some programming this week and think I got a working setup with light and even a buzzer for reversing light.

I am new to Arduino so my code is probaly very simple and slow.

I notices that after adding reverse light the all project is getting slow.

If you have time I can send you my code and you can look at it and maybe find some adjustments that can be made for speedign the code up

 

But It would be interesting to see you code and see if I can contribute or use some funtions in my code

Share this post


Link to post
Share on other sites

OK, long time no update - it's been a bit of a crazy few months with one thing and another, but I have been secretly working on the Arduino MFU as a side-project for a while.  However, I've been working on it in a unit test environment and until tonight I haven't been able to test it on a physical device.

I managed to break away early from my household chores, dragged my King Hauler development rig down from storage, and hooked it up to the laptop to load the latest version of the code.

The good news is that my failsafe code (sort of) works.  It needs some fine-tuning because I'm getting more than a few false failsafes, but it is working.

The bad news is that the addition of an IRremote library for sending data to the trailer is causing the entire thing to slow down.  I'm not sure if it's a timer operation in the library affecting the main clock speed, if there's some kind of delay in the library, or if the library is genuinely inefficient to the extent that the Mega has slowed right down.

Having looked again at the price of a Beier unit (which will run with any motor and battery) compared to an Arduino Mega, modified handset, batteries, motor, battery, transmission etc. and suddenly it's not looking so expensive after all, especially when I consider the amount of time I've put in so far and the amount of time I'll have to put in to get around this IR problem.  If I was an expert with C++ then I could probably rip apart the library and work out where the slowdown is occurring, but I'm not, and it doesn't look like my work will give me the opportunity to put all these new C++ skills to the test, so it might be time to park this project and put my time into something else for a while.

I have briefly considered using a Raspberry Pi - but I'll need some additional hardware to convert the 5v PPM from the radio to the 3v necessary to communicate with the Pi.  I'm sure the code could be ported without too much bother (at least I have a full unit test suite to start with) and Python is a current language, so I might even get to use it at work, but I'm so busy with other things that I don't know if I'll get around to it.

If anyone is interested in seeing the code as it is then let me know and I'll make the library public on Github.

  • Like 1

Share this post


Link to post
Share on other sites

OK - so a thought came to be last night, as I was lying awake thinking about splashing £220 on a Beier MFU.

LED lighting can still be achieved by passing the responsibility out to another Arduino.  I'm pretty sure it could be done with a plain old Uno.

Currently, the trailer code serialises all the lighting settings and the servo values for the 4 aux / park channels and sends them over IR.  Well, all of that data is already being output through Arduino pins.  In theory all I need to do is split the output pins so that they feed both the lighting board and aux servos, and a second Uno (a surface-mount Mini in the production version).  This Uno will then have the responsibility of reading those values, serialising and transmitting over IR.  It adds a bit of cost (minimal, a Mini is a few quid), and a fair bit more manual work (making yet another hardware board) but doesn't require much new code and means any delays in the IR Tx board will not affect operation on the primary board.

At some point I actually need to turn all this code from badly-wired prototype into functional primary board.  The Drag King project is taking a long time to finish due to the amount of custom fabrication required so I might pull my Globe Liner out of the box and turn it into my testbed.

Watch this space - again!

  • Like 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...